Hunting

We’re taking a slight segue here and going to cover some topics around finding a job.

Having recently relocated home to Sydney Australia after 6 years in the US,  I found myself back on the job market in an entirely different economy.

Some very basic observations after a few weeks of job hunting:

1. Pay attention to when the financial year ends in your job market. Traditionally, Australian companies finish their financial year at the end of June. In the US, it was usually Dec. Either way, the quarter leading up to it is usually slow as companies crack down on budget to hit numbers.

Note: Unless your looking at public sector roles. In that case, it’s sometimes “Use it or lose it” and you will see government departments spending up big in the last quarter.

2. Despite the first point, there are always positions available. Even when it’s “slow” the companies that are hiring are serious about it.

3. Surprisingly – It’s not about the technology. With more and more software development moving off-shore, I found my Project Management background of much more interest to companies then my background managing technical development teams.

4. Linkedin, despite being the predominant networking and recruiting tool in the US,  plays a cursory supporting role in Australia. Use SEEK. That’s what everyone else does.

5. Recruiters are a necessary evil. Almost all companies have PSA’s (Preferred Supplier Agreements) these days, which means they work exclusively with a handful of recruiters. Whilst there are some organizations that will only recruit directly, your chances of getting your resume into a company are much higher if you get it into as many recruiters hands as possible.  Remember – they only have a handful of jobs each that they are trying to fill, so only working with  a few does not get your resume out there.

You can complain about the fees (particularly if you’re looking at contract work) but at the end of the day – They are paid on commission, and you are a commodity that is being sold.

Very early in my career, I spent a year moonlighting as an IT recruiter. It was during the dot com boom at the end of the 1990’s, and it was much less structured.  If you had a very good candidate, it was easy to become their advocate and reverse market them to companies you thought were interested.

With the increased prevalence of PSA’s, that’s increasingly rare. The recruiter’s customer is the Organization. Not the candidate. You’ll see their behaviors change if you get to 2^nd interview stage.  Your best mate will suddenly become a bit more insistent. They will push you to take the role, even if it’s not the best one for you. Which should be expected – they only get paid on placements.

6. It’s not about compromise.  Luckily, I don’t have children to support, so there was no urgency to accept a role that didn’t tick all the boxes. Be careful of falling into the trap of having to choose between a good job and crap pay, vs a crap job and good pay.

That’s a suckers choice.

If you're patient – you’ll find roles where you won’t have to make that decision.

So what was my experience like?

Despite it being the end of financial year, and dire warnings about the GFC,  surprisingly good.  I kept a log of my 2 week search so I could keep all the agencies/jobs/companies straight and the numbers ended up:

• Applied for twelve roles
• Interviewed with Agencies for Six
• Interviewed with Organizations for five
• Second interviews at four
• Offers received for three of them within 2 weeks.

That was much better than any of us expected. Friends, recruiters and myself included.

In the next post, we’ll cover how to make yourself more marketable.

How is your physical environment affecting your productivity?

We'd just moved the group downstairs to an open plan team area. They had spent the last 4 years in cubicle farms and we'd unceremoniously kicked them out and thrown them into a massive room with a few trestle tables and whiteboards covering the walls. Now that I reflect on it, they probably expected the white walls to be padded.

There were two of us standing near the storyboard surveying the room, and my colleague quipped "Wow, It's so quiet in here you can hear the waterfall".

Which reinforced several things to me:

Just because you do certain things it doesn't make you agile. Having a daily stand-up, a story board and an open plan environment are not by themselves agile. It's the behaviors that those techniques encourage that is important. Be careful of falling into the mechanical agile trap. 

So what is it about having an open plan environment that supports an agile implementation?

1. Communication boundaries are reduced. This seems obvious, but the very tools that have made communication more efficient can be mental barriers to open communication and collaboration. Not picking up the phone, Not leaving the cubicle, knocking on the closed office door, writing the email instead of having the conversation. These are all relatively minor barriers that inhibit the flow of shared information. In an open floor plan you can share information and make decisions faster because everyone is right there.

2. Learning through Osmosis: I've lost count of the amount of invaluable things I learnt purely by overhearing conversations around me. Useful things. Hearing a developer walk a tester through changes or a Product owner sitting with a Tester as they describe use cases. As a project manager - that's all invaluable.

3. Transparency: There literally is nowhere to hide. You can see everything that's going on.

There are obviously cons as well when not implemented correctly. For some people it's really hard to get into the "flow" because it's hard to concentrate, I find that most people usually adapt within a few iterations and get used to working in such environments. 

A warning though - make sure the teams you have seated near each other make sense. They had once moved our development team next to the first level support team for another product. There was very little useful cross pollination going on and everyones productivity was impacted. 

There's a much better article here:

http://www.logigear.com/magazine/agile/proposal-for-an-open-work-space/

Fear does funny things

Have you ever worked in an environment where there was an overriding sense of fear behind decision making and team behaviors?

Do you ever notice people are very quiet in meetings when you know they disagree? 

That's what we had for a long time. 

I still recall the Project Executive standing in the middle of the open team space and yelling "I'm going to fire you all and start again" (He also had other gems like "Conflict breeds performance". But I digress... ). The main point was that the teams were driven by fear. 

Ironically - so was the Exec. It was his butt on the line if the project failed again. 

No one likes to fail and get thrown under the bus, and it had been going on for 4 years. I even had developers that were too scared to touch their keyboards.

Fear of failure and the corresponding repercussions can lead to perfect charts like those below.

Agile teams should make mistakes. They should be allowed to fail. In fact there is a general motto of "Fail fast". The emphasis should be on how fast they get back up, dust themselves off, learn from the mistake and re-adjust. If they never fail, they're probably sand-bagging.

Does your work environment allow for failure?

An example I use is that of a tightrope walker. If you want someone to learn to get to the other side fast, the best thing to do is install a safety net.

Otherwise they won't even take the first step.

Finding defects is part and parcel of software development. You can slam the development and testing team for letting one escape, or you can set-up an environment and behaviors that catch them as soon as possible. Test Driven Development. Automated Tests. Continuous integration.

Fail Fast. It's the best way to succeed.

What behaviors are you rewarding?

It was 2 weeks into the project and the team environment was still hostile. 

Not just "challenging". Hostile. I was running out of ideas.

I had always prided myself on my ability to build cohesive, productive teams and a spotlight had just been shone on how limited my tool belt was. When you contract to a public sector department -  you can't take the team out for lunch or drinks because they don't want to risk the perception that there was any "bribery" involved in the contractual process.

The side-effect is that I had to start learning to use other tools.

Candy started appearing at work. The small things that are normally overlooked got rewarded and praised. A gong appeared so that the BA's could hit it when a story was approved and accepted. This was usually proceeded by applause and cheers from the open floor. If you're reading this with cynicism, I can empathize. False praise doesn't motivate anyone...

It's funny how far sincerity and genuine good intent will take you though.

A lot of management theory relates to rewarding performance or results. In the last year or so, I've taken to rewarding the behaviors that lead to those achievements; rather than waiting for the goals to be achieved and then rewarding that.

Why?

Imagine you set a New Years goal of running a marathon. Are you more likely to give up at the beginning when you have just started training or at the end? When will you need the motivation and support from friends and family? 

Reward the right behaviors during the tough times and the results tend to follow. Besides, then you get to go to the pub again when the project releases :)

This video is highly recommended:

The power of Three

I recently sat through a UI session with some developers and business analysts as they tried to choose between 2 design options. The situation made me consciously recognize a tool that I use a lot in meetings to help drive decision making.

On the board were 2 implementation approaches that the business analysts were trying to decide between and struggling with. So I added Option 3: Use what the base product provides and not code anything. We all knew it wasn't a viable option, but it provided context that the two other options we gave them were so much better that they could go with either one and be much better off.

It's seems like a silly and simplistic technique but there has been quite a bit of research done on it.

Choosing from:

• No options: This is generally a bad idea unless it's specifically a brainstorming session or a "Understanding the problem" session. Otherwise the discussion tends to go around in circles. 
• 1 option - No one likes being left with no alternatives
• 2 options - You start second guessing whether you should have chosen the other one.
• 3 options - My perfect number 
• 4+ options - “The more options there are, the easier it is to regret anything at all that is disappointing about the option that you chose.”

There's an interesting TED talk about the Paradox of choice below. 

So next time you want to drive a meeting to a decision point, remember the power of three. 

Can something be too perfect?

Another common fallacy with agile delivery methods is that there is no proactive planning and tracking. I wouldn't call that Agile.

That's more "Cowboy".

The common tools I use are burn-down and burn up charts for iterations and for releases. It gives you an idea of what you have left to do for each milestone at a quick glance, and whether you're in trouble.

Over the last year, I've leaned towards just doing burn-up's and only at the story point level. Once you start tracking hours against tasks, the management cost increases exponentially without the corresponding benefits. You could theoretically extract resource utilization data from it, but I rarely see that data used. Remember - There's no point capturing data if you're not going to use it. 

In the example below, the story point goal was ~800 points. The dark green represents what was accepted by the PO. Due to organizational dysfunction, We were utilizing more of a kanban approach and were demonstrating as soon as features were completed and tested rather than waiting until the end of a sprint. This method had pro's and con's which I'll discuss in a separate post.

We emphasized with the team that it's much better to get stories done and accepted all the way through the cycle and not letting things sit and slamming QA and the PO at the end.

After several iterations we started seeing these patterns in the burn-up:

An almost perfect linear line from iteration start to the goal.

That's a good thing right?

Or is it a little too perfect? 

To answer that - you have to understand the team, the environment and their motivations.

Does your business know their business?

It's a question that most people are scared to ask because it rocks the boat; self preservation leads most people to avoid doing that, as you never know who might fall off.

I remember reviewing a product backlog and wondering how the prioritization was done. The highest value stories did not appear to be at the top - nor the smaller stories that might give the "biggest bang for buck". 

Then I noticed it was stacked with requirements from our most "vocal" customer and the most recent requests. Essentially whoever nagged the Product Manager recently got their requirements moved to the top.

On another project - it was clear that the Business Analysts didn't understand what they were really asking for. They were copying and pasting requirements from an existing list. There wasn't much analysis going on.

When this occurs - it doesn't matter how good your delivery team is. You need a good Product Owner.

DDD - Defect Driven Development. Do you need a Defect Management System?

A friend coined that term on a recent project. He was shaking his head after a painful interaction and said - "We don't do TDD here man. We do DDD."

This post is going to cause some arguments, but hear me out.

I had never worked on a project that did not have some system for tracking their bugs, even if was just a horrible spreadsheet. Then I worked on one where we purposefully delayed setting one up, and delayed it again.

And then I questioned if we should ever have one.

Some observations:

On the projects that I did have intricate tracking systems, I spent a lot of time reviewing, prioritizing and assigning defects and escalations. So did my Development and QA managers; which was a significant loss in productivity. It got to the point that they implemented an "Aging" process. 

<Cue screaming from QA folk.>

Yep - There were so many bugs logged that every few months they'd run a query to close out any incidents that were older than x days.  If it was really that important - someone would have made noise or it would have been re-raised. Keeping them there was cluttering up the queue and making it hard to identify the real issues.

So what behaviors did I see when I didn't have a Defect Tracking system?

• Testers bringing issues to the devs straight away rather than bugs queuing up.
• Face to face interactions and discussions as opposed to relying on a system as the intermediary
• Less noise was created  - bugs were actual bugs, requirements or anything sufficiently large got moved into the backlog and prioritized appropriately.
• Less lag time as a ticket was passed back and forth for "more info", "not reproducible" or "works on my machine"
• People started taking pride in the quality of their work
• I never had to deal with another "bug fix" sprint.

What are the usual arguments against this crazy concept?

• "I need reporting to track what quality levels are like" - That should be a quick report. You have zero bugs. Here's a pie chart.
• "But aren't you distracting developers who should be working on features?" The developers are currently writing code on top of existing buggy code. so they're currently coding more bugs, not features.
• "But the Devs are 'in the zone' I don't want to disturb them." Try disturbing them in 6 months with something they should have fixed at the time or that some other developer did and they have to debug.
• "Doesn't that impact your velocity?" Not noticeably. If you have that many defects  - you have a much larger code quality and development process issue. Its going to impact your velocity much more if you pile up the technical debt and try and deal with it later. 
• " This isn't a two-bit project like the one you're describing - This is large and really complicated"….

Trust me - I didn't think it would work either. 

Then it did.

Embrace the WAG

I think this is also an British acronym for Wives and Girlfriends - that could get you in trouble. Don't do that.

I'm talking about the "Wild Ass Guess".

Trying to prioritize a product backlog is like Window shopping. You can prioritize all the things you want at the top of your list, but unless you have some sort of idea of cost, it's not really effective.

In a waterfall project, you'd have a design phase where you worked out how to accomplish the requests, then do detailed work breakdowns to identify how many hours/days/weeks are involved to complete the work.

That's a lot of effort and time to invest in something that you may not even want to build.

In most cases the WAG is good enough to allow the Business and Product Owner to prioritize. 

I've taken a liking to T-Shirt sizes:

• Small, 
• Medium, 
• Large 
• X-Large etc. 

It allows the Product Owner to compare the features, but doesn't get you bogged down in the "How many hours?" discussion - which isn't really useful.

Perception is reality. Especially to the boss.

How involved is your senior management in the day to day?

Probably not a lot.

Which is why it's important to involve them in the Iteration demo's and publicize team achievements and project milestones. This isn't about blowing your own trumpet - it's about keeping the team productive.

The concept of the self organizing team is alien to most managers. A lot of them have probably gotten to where they are using a directive management style. When those management types can't see progress - they usually assume that none is being made. Then they start interfering and trying to fix things that aren't broken.

So make sure progress is visible and publicized - because perception is reality.

I like to spike.

One of the hardest parts of moving towards an agile delivery approach is guiding teams to build functionality in thin slices. We've been so accustomed to building using traditional design techniques that it's hard to let it go. 

With technology projects, so much of your design is based on assumptions and unknowns. When you eventually build it out, you've usually deviated from the design in multiple places due to things encountered during the project. So if the design is more of a "guide" why spend so much time on it?

A spike is there to help you discover those unknowns, whilst delivering a thin slice of functionality. 

This allows you to show something to the business to validate whether you're on the right track, understand whether the technology can do what you want and whether your initial WAG is accurate.

Always keep a spike in the tool belt.

Can you take a smaller bite?

Following on from a previous post - Small stories are cleaner, easier to complete, faster to demo and quicker to accept.

But what do you do when you can't split a large user story into a small enough chunk that still delivers value? 

This XP article is useful - but one of the most useful tools that sometimes gets forgotten is to remember the law of diminishing returns. Sometimes wrapped up in the guise of a single requirement, are multiple smaller/ less valuable features. Look for the portion that's going to give you the most bang for your buck. 

Break everything else out into other stories. 

It's like giving your Product Owner an itemized quote rather than a all-inclusive one, and all of a sudden they have the ability to prioritize better.

You'll be surprised as to what they'll "live with" when they can see how much it costs.

Believe it when you see it

The value of iterative delivery is that it allows you to inspect often.

I'm sure you're all experienced the problem when someone tells you they're done and then you find out later that they were "mostly done - like 80%". 

We all know how long that last 20% takes.

So this introduces two important concepts: The definition of done, and not believing it until you see it.

When someone tells you the requirements are "Ready" you'll want to review that before throwing it into the backlog and bogging down a team.

Similarly, If demonstrating everything at the end of a iteration is too onerous - then demo as you go. 

Whatever you do - make sure the project sponsors and stakeholders see it occasionally as well. This transparency helps avoid other issues.

Analysis Paralysis - The "What If?" problem

You're in meeting trying to understand or solve some business problem - when someone throws out the dreaded "What if" or "How do we handle?" question. Sometimes it's a valid scenario. Sometimes it's an edge case, sometimes you suspect the person has been tripping and has taken it down some weird unrelated tangent.

It becomes a much larger problem when it drags the discussion into an infinite loop; When a decision can't be made because you're trying to handle so many different scenarios it's become a muddled mess. 

At this stage - Park it. 

Acknowledge the scenario, write it up on the whiteboard and agree to discuss at a later time. Most of the time it should end up being it's own scenario covered seperately..

I had a CTO once who was outstanding at this. He'd acknowledge what you brought up, write it up on the whiteboard and say "That's a great thought - Let's put that on the board, finish this off come back to that"

It took me several months to realize he never came back to any of it; Or had any intention to. 

I guess that's less of a parking lot - More quicksand. He's probably a bad example.

...But what if he had come back to it…?

Unless you see a hairball, keep grooming

We've discussed the value of keeping momentum going in a previous post.

One of the things you never want to see is a team stopping because there aren't enough requirements ready or they're not prioritized. I call it the Prairie dog - You should never see the team pop their heads up and ask - what do we do next? You want them focused on getting things done.

I've worked on large programs where this was a serial process and a real waste of productivity. Don't wait until you finish one release before you start gathering requirements for the next.

This is what you don't want to see:

You don't want idle time between iterations and releases. 

What I prefer to see:

You can take this too far though. 

The product backlog is meant to be "purposefully vague" as it gets further down the list. There's no point spending lots of time getting a User Story clean that may be months or years down the pipeline.

So focus on the high priority items at the top of the list - fill out the rest of the wish list later.

How much documentation do you need?

I'm not talking about User documentation or Help - I'm talking about all the supporting artifacts that get created during a project lifecycle.

This is a seemingly innocuous question but is usually a good gauge at how productive your project really is.

How much of the supporting documentation for your project is actually consumed? 

How much of it is produced to satisfy your development process?

How much of it is to keep external stakeholders happy?

How much is created for reporting or metrics?

Who is actually consuming it? 

It's easy to get caught up doing "Busy Work".

My guidelines are:

1. Do enough so that you have control over the project

2. Do enough so that your boss trusts that you have control over the project. 

That's it.

If you don't need it to actually keep on top of things - don't waste time producing it. Because then you have to maintain it, and next thing you know you're spending all your time editing docs instead of producing value.

If you don't keep your boss happy and up to date, they're going to come and poke around and probably distract the teams doing the work. So work out what they need and how often they need to see it. From experience, It's rare that a weekly report and an invitation to product demo's won't cover their needs.

TLA's

If you read the Project plan post, got very angry and yelled at the screen "That's why you should have a Change Request Process dumbass!"  - Thanks, that sets up this next post. By the way, You have some repressed anger management issues - you should probably talk to someone about that.

Let's listen in on a conversation I have with myself regarding Change Request Processes.

For this example, My personality has been split in two: Three Letter Acronym (TLA Me) and Agile (Ninja Me).

Ninja Me: Why do you have need a Change Request Process?

TLA Me: So I can document when we have deviated from our original plan

Ninja Me: Couldn't you just have a quick chat with the Product Owner and Team and if they agree it makes sense, just re-prioritize the order you're doing things?

TLA Me: But it needs to be traceable

Ninja Me: So make sure you log it. Or use a system that has it for free.

TLA Me: But all the stakeholders need to be aware, and then we have to re-plan, and re-estimate.

Ninja Me: Hasn't everyone already agreed it needs to happen? If you have a definitive finish date, then whatever was at the bottom of the list just became less likely.

TLA Me: Ah-Hah! That's exactly why. We just changed scope and impacted dates!

Ninja Me: You're also delivering what the customers and stakeholders actually want- not what they asked for months ago. 

TLA Me: But won't I get in trouble?

Ninja me: So this is about CYA?

TLA: Hey, TLA's are my job

Ninja Me: Sorry. My bad. How much time do you spend chasing down Change requests, re-estimating it and re-drawing the project plan?

TLA Me: Most of my day

Ninja Me: And you get Developers and testers to help you with the documentation, task breakdowns and estimates?

TLA Me: Of course - otherwise it wouldn't be accurate

Ninja Me: So who's doing any work?

TLA Me: Let me look at my project plan. I'll get back to you.

I need to drink less coffee...

Do you know your Purpose?

Most Projects have some goal or end state.

Some even have fancy mission statements.

Very few clearly define the "WHY" - What is the purpose or reason behind what they are trying to achieve. 

This can lead to several problems:

1. It's the Purpose that drives the actions. 

It's the real motivator. When you know why you are doing something and it's a powerful enough reason - you're much more likely to get the end result you're looking for.

2. Sometimes understanding the "WHY" leads you to a totally different end point or solution. 

Ever have that lightbulb moment when you realized what you built wasn't what the customer really wanted? If so, You probably didn't understand why they wanted it. 

     This is why user stories are structured as:

          As a <role>

          I want <goal>

          So that <why>

The last part of a user story that justifies why someone wants something is very important.

3. A lot of the arguments/ long discussions that occur during a delivery cycle are usually differences of opinion on "How" to do it. 

The design, tools used, Process etc... People can get pretty dogmatic defending their position. 

You can circumvent these a lot of the time by refocusing the discussion back on the purpose behind what you are doing. As long as you solve the "WHY" The How is less important. 

As they say - There's more than one way to skin a cat.

Mine is better though ;)

"No plan survives first contact with the enemy"

It's a famous quote from a German field marshall named Helmuth von Moltke (The Elder). 

I believe Helmut was reincarnated as Scott Adams, though I have nothing to back that up with.

I recall a project where the Program Manager was very quick to announce during status meetings that we were "executing to plan". Her measurement of success was how well we were marching against the detailed project plan that had been meticulously put together over several months. Unfortunately this was flawed for a few reasons:

1. The plan was terrible.

2. If she'd talked to Helmuth, she would have realized that it was essentially out-of-date the moment the first task was started.

What pattern do I normally see?

Very late in the project, the status flips from "Green" to "Red" because executing against a plan doesn't mean you're really "done" or meeting the customers expectations. You are no longer reacting to or basing your decisions on reality (both status and environment) and the repercussions of discovering that late in the cycle are usually costly.

Of course - Project Plans and Gantt charts can be very helpful when used correctly. I still use MS Project to map out release and integration milestones. It gives Executives and Stakeholders the ability to see at a high level what is happening/when in.

But a detailed MS project plan does not a successful project make.

The wand won't work

I just got back from a day at Universal Studios in Orlando. One of the highlights was visiting the Wizarding world of Harry Potter section. We toured Hogwarts, drank butter beer and browsed through Olivanders wand shop. I even bought a magic wand.

It just doesn’t work on my projects.

I'm sure you've heard about the triple constraints of project management. It basically holds that adjusting any of the 3 sides of the triangle has a direct effect on the other 2 sides. Unfortunately moving to an agile delivery method does not give you a free pass to avoid those constraints.

Sorry.

But what if you can make one of those sides flexible?

An all too common scenario I've seen is when Sales or Product Management have promised a fixed set of functionality to the delivered within a set time frame, and it's up to the Development team to deliver.

I've seen Product Requirement Documents that have had hundreds of really large requirements all listed with a priority of "Must Have". The cavalry of reinforcements never arrives, leaving the team in a no-win situation: 

• If you're at a Public company, this leaves you with some revenue recognition issues if you booked sales based on features not supplied
• There's a hit to the company reputation for missing delivery dates
• That sort of pressure on a team does not make a pleasant work environment. You're going to see staff turnover if you set them up to fail like this.
• There's still no commission for the Sales guy.
• Someone decides to ship anyway - with incomplete features or buggy code because you ate into your QA time. That leads to a raft of other problems.

So how do you solve it?

The easiest side of the triangle to build in some flexibility with is the scope. The other two sides generally require acts of congress to move from my experience.

When you have so many things to deliver, and you are delivering them with waterfall techniques, it's quite easy to fall into the trap of spreading yourself too thin across multiple requirements concurrently - and successfully completing none. 

So take the wish list - and stack rank it.

If you could have just 1 feature. What would it be? 

What next?

If your business can't answer those questions - your problem isn't a Project Management or Delivery one.

Convincing the Biz.

There are a couple of things to take into account when trying to effect any change:

1. It's not how much you are doing that matters - it's knowing what you are being scored on.

2. Take Baby Steps.

3. Most New Years Resolutions Fail.

Let me be a little less cryptic:

1. Have you ever felt resentful because you feel like you do/contribute  a lot - but it isn't appreciated or recognized? 

Firstly, a personal example:

I worked from home for several years when I first moved to the US. It had it's pro's and con's, but having the time to do chores like washing and cooking during breaks in the day was particularly useful. Despite all the housework I did, my wife still seemed unhappy with me. So I did more. She still seemed unhappy. That just made me resentful. Then I worked out that what she needed from the relationship was for me to take a break from work when she came home was to drop everything, give her a hug, and spend some time paying attention to her. 

I was putting in a lot of effort - but not in the areas I was getting scored on - so they didn't count. Now we eat out a little more, we're a little chubbier, the house is a little less tidy, but we're both happier.

Until she notices that I used this example in a blog post.

Successful relationships are about meeting each others needs and that basic rule holds true in any relationship - including a work one.

So how well are you meeting the needs of your sales and marketing groups?
What about your boss?
Do you really know what their needs are?
Have you asked them - or are you assuming?
Are you putting a lot of effort into the wrong areas?

Maybe you are meeting them too well at the moment and they see no need to rock the boat and change the way things operate? (though you probably wouldn't be reading this if that was the case)...

Or do you need to do a better job of communicating how your proposed changes can help meet their needs?

Do they:

     Want predictable release dates?

     Want to reduce development costs?

     Want to deliver features that meet customer expectations?

     Want to reduce maintenance and customer support costs?

     Want to reduce time to market with a new product?

Work out what it is they want most - and then show them how you can help get them there. Usually - One of these can be enough of a reason to initiate changes. You just need to work out which one has the most leverage in your organization.

2. The phrase comes from a scene in "What about Bob" that has stuck with me for quite a long time. 

This seems really obvious, but - start small.  Find an exec or sponsor that is willing to support it. Identify a Business Rep that wants to change and partner them with a good team. Call it an experiment and promise to go back to old ways if it doesn't show results.

Time-box it.

Celebrate and publish the successes using metrics they understand. You can build from there. I've seen quite a few transformations fail that tried to change too much too soon and it was beyond the organizations comfort level. 

Ironically, they weren't iterative with their agile transformation :)

3. 72.8% of New Years resolutions fail. (Homer Simpson helped me with that statistic).

Good intentions only get you so far. Sometimes the best leverage and driver for positive change is when you get sick and tired of failure. It's the tipping point that forces you into action. If you look closely enough for them - You'll find areas in your business that are struggling and are willing to try something new. They are sometimes the best places to start - because the contrast when you succeed is so much greater.

P.S - I'm currently on a Caribbean Cruise so this post is not real-time. A friend pointed me at Hoot-Suite not too long ago and I've found it very useful for scheduling and tracking your social network posts.

The "Commitment" fallacy

"We're not using agile - that's just a way for you to not commit to deliver anything. How can I base a marketing roadmap off that?"

You've heard variations of that i'm sure.

A common misrepresentation is that you when you deliver using in an iterative fashion, you don't focus on the entire scope of the project and you don't commit to deliverables. This scares business people. It would scare me too. If only it were true.

It's generally accepted that even a traditional project plan built from the bottom up is likely orders of magnitude inaccurate. The cone of uncertainty depicts that quite well. 

If a team can't give you a good ball-park estimate on what you'll see at the end of the project, it's probably because they know your business requirements are going to change over that timeframe.

And that's allowed. 

Instead of thinking if it as a bad thing - think of it as a better way to react to the changing environment. How quickly you can react to fulfill a customer need is a success criteria every business should use.

Besides  - you won't have to fill out any more change requests.

Agile. Just like Fight Club.

The first rule of selling agile, is to not talk about Agile.

For "Old School" technologists - it's a buzz word that they are immediately cynical of. This is also true of a lot of other terminology. When I've snuck in agile practices in the past, I've used "Phases" instead of "Sprints". "Scenarios" instead of "User stories" etc.

Use terminology that the organization is comfortable with.

A friend (Let's hypothetically call him Scott) mentioned recently that convincing the business is often the hardest part of an agile transformation. That made me realize that for a lot of the implementations I've been part of - the transformation has been driven from the grass-roots level. It's rarely senior management driving the change - it's usually a lone dev team or sometimes just one manager who decides that there is a better way to build software - and does it. It's always easier to ask for forgiveness than for permission.

So how do you help the organization or business transform, when the Dev team is already champing at the bit?

Tune in next week - Same bat-time, same bat-channel.

Eating the Elephant

I love Man vs Food. 

It's indulgent, over the top, and somehow the host manages to accomplish ridiculous eating feats that you don't think are possible. 

And he does it one bite at a time.

Iterative development forces you to deliver some working piece of functionality every iteration. So realistically you can't go too far down the wrong path and lose too much time, because you'll be reviewing and readjusting your course every few weeks. 

How do you break down a piece of functionality into small enough pieces that they still deliver value?

Let's start with how you don't do it - When you're building tiered technology, you do not break it along those layers. For example - I would not have separate stories for the DB portion, The business logic and the UI. Each piece by themselves do not deliver any real business value. 

Remember - we're looking for fast feedback from the business - and demonstrating some DB tables, indexes and views isn't going to get you that feedback. 

As a general rule, people are pretty bad at defining what they want in any sort of detail. Those same people are usually much better at telling you what they do/don't like after seeing something. So build a small piece of it, show it to them, get their feedback, and then adjust. 

They may decide they don't really feel like Elephant for lunch; and that they're in the mood for sashimi.

Forget the handshake. Embrace the group hug.

In a work appropriate manner of course. I wouldn't want to see any of you get fired.

A lot of traditional project management revolves around hand-offs or handshakes; Sign-off's and documentation.

The entire cycle from Requirements Gathering -> Analysis -> Design -> Functional Specification -> Sign-off can usually be shortcut by throwing the right people in a room with a few whiteboards and telling them to have a conversation. 

In a past life, the company I worked for moved our Program Management Group under a VP who was tasked with improving product quality. His first initiative was to establish a "Product Creation Lifecycle" that involved passing 20+ gates before anything could be released. Each gate had upwards of 10 deliverables - The majority of which were never consumed. In theory it worked - We didn't release any more buggy code.

We didn't release anything at all.

Good Project management is about how you can speed up all the feedback loops in your process and get business value to the customer.

So rather than thinking about "How do I stop getting bad quality software into a customers hands" - Focus on how fast you can get good quality features to them.

Less documentation and reviews. More conversations.

Less process. More good people.

Less handshakes. More group hugs.

Whiteboards are your friend

I love whiteboards.

One of the first things I do on any project is get lots of whiteboards installed for impromptu design and troubleshooting sessions.

But they're damn expensive. 

On the last project though - a colleague introduced me to shower boards and i'll never go back. The coating on them makes them usable as a dry-erase board and you can pick one up for $15 instead of $500. Check out this happy guy.

3M have also started selling a sticky note version of a whiteboard that can be a less permanent fixture.

Glass walls and Windows are also great.