As Marty Andrews wrote, “At this point, the stories have not been prioritised. They have been classified into groups, where the group is named “Priority One”. Whilst this may be a useful culling technique, do not fool yourself into thinking they are prioritised.”

Agile forces you to enumerate the list of features (stories, in the agile world) in a single list sorted by importance. The team will work down the list until they have used up the time for that cycle.

The benefit to the implementation team is obvious. There is no ambiguities on what is being worked on. Sort the list how ever you want, they’ll start at the top and work down.

So, how is this good for the product team that didn’t want to make the Sofie’s Choice decision? They realize after a release or two that what wasn’t done last month (pick your weeks… most methodologies suggest 4-6 weeks per cycle) will be at the top of the list next month. Also, there’s no stress involved with the we need everything, including the kitchen sink, because it will be 6 months or a year before this product sees the light of day. It’s not true. If you forgot a feature, you can include it next month. If something low on your list actually should bump up much higher, again, adjust it for next time. The pressure’s off and everyone is releasing product.

When I was a kid, I loved the Garfield comic strip.  Now, not so much.  But take a look at Garfield Minus Garfield.  As the site says:

Who would have guessed that when you remove Garfield from the Garfield comic strips, the result is an even better comic about schizophrenia, bipolar disorder, and the empty desperation of modern life? Friends, meet Jon Arbuckle. Let’s laugh and learn with him on a journey deep into the tortured mind of an isolated young everyman as he fights a losing battle against loneliness in a quiet American suburb.

Now, my kids love Garfield.  But this new missing context Garfield brings a new perspective to this strip that I find amusing.  It really illustrates the point.

They only see short term benefits of reducing headcount, but do not change overall business goals.  Inevitably, staff needs to be ramped up to meet demand, thus raising the cost once again.

Reduced team sizes are still expected to perform the same duties of a larger organization.  This results in a direct impact on delivery/quality.  People are stretched too thin, mistakes are made, morale decreases.

Depending on the business/IT plan, outsourcing/contracting savings sound good, but generally do not include the total cost of ownership (TCO) required to create NEW products/features.  You still need to invest in training product domain knowledge, rampup… Without strong internal knowledge, you invest the technical direction to a 3rd party whose pay increases proportionately to the amount of work they do.  So there must be budget for a core group of subject matter experts (SME) who can interpret business direction, define a compatible IT direction and direct the vendor.  In order to achieve long-term benefits, you must invest in automation (code reviews/standards enforcement, testing) and agile processes… These will reduce volume of resources required, but it does increase the short-term need for higher quality individuals both with the vendor and internal staff.

True long term cost reduction is obtained via quicker time to market and increased quality of production level code.  Reducing the staff to do this should be done with a well thought out plan with these goals in mind.  It may require changing out your staff to achieve this, if they are not willing to help achieve these goals.

Outsourcing isn’t bad.  Many of these companies perform IT at a level most companies do not have the time or finances to evolve their internal organizations to.  They invest in reusable assets, automated tools for all facets of product development and testing.  Additionally, their labor in offshore, onsite/offshore models are incredible competitive.  Further, they are incredible solutions for lifting/reducing cost of maintenance of legacy or repetitive processes/jobs, allowing a companies staff to focus on new/extending applications.  Companies should focus on strategic resourcing model and not quick gains to make shareholders happy. 

it’s a marathon, not a sprint

Sounds great!  Why would I say they are bad?!?  We should have more of them!

Oh… well, most of the time, they are working around the clock because they lack any organizational or planning skills.  They didn’t realize how much it would take to do it, so they are rushing.  Often, they don’t design what they are doing, they just do it, hence their estimates are usually way under.  Ever wonder about those last minute “killer bugs”?  They get the work done fast, but it’s sloppy.  There are holes in the logic, little error handling, no thought of performance.  They made it look cool and it does exactly what it was asked to do.  Any faults are with the user of the system, not superman.  Don’t even ask about maintenance or ease of enhancements.

Give me an office full of Batman’s any day.  They are the backbone of the organization, the work horses.  They plan, investigate, research… they are the detectives who are aware of their own mortality and that of their code.  They don’t come in everyday asking how they can save the world, they plan for building a solid foundation, determine how to get from here to there and setout to do it in a calm, orderly manner.  They are predictable, but have deep insight due to their solid understanding.  The don’t seek the limelight and thanks for saving Gotham, but are satisfied with just doing their job well.

1. business defines ask
2. dev/qa/ops define cost/timeframe
3. business redefines ask
4. dev/qa/ops redefines cost/timeframe
5. business sets hard date for launch
6. dev/qa/ops redefines ask based on cost/timeframe to meet topdown date

 The benefits of agile for me are in the planning, scope definition. The team cuts to the chase and starts with a timebox and works together to decide what can fit in there. Since the timeboxes are consistent, there is much less resistance in dropping features because the business can easily predict when they will be released. That’s a big difference from the waterfall approach where there’s no predicting when the next release will take place

There are several other benefits that come from an agile approach. Product, Dev and QA spend less time defining in detail the feature, design and test cases prior to construction. This was one of the points that seemed counterintuitive to me in the beginning. My knee jerk reaction is to demand more detailed definition up front. I’ve read all of the findings and lived the reality that it’s easier to fix a bug in the documentation than in the code. With agile, there is a higher level of collaboration and prototyping. I began thinking of this as less agile and more evolutionary development. The team starts with a handful of ideas and iteratively builds on them. If you don’t get it perfect (and you won’t) the first time, you improve it the next release. And if you find your estimates were high, add a feature from the backlog. If they were low, drop a feature to the backlog.The idea and goal is predictability, collaboration and prioritization. When you involve everyone in the planning, the discussion of cost to implement becomes academic and not emotional. There are 3 features on the list. Each feature takes 5 days of effort. Your resource pool has 10 days of effort available. Pick the 2 features you want to get done this release and put the 3rd on the backlog for the next. There are tools in place to deal with what are normally challenges in a waterfall. The team is now free to focus on releasing product, not debating what can be done in what timeframe.

The art of war teaches us to rely not on the likelihood of the enemy’s not coming, but on our own readiness to receive him; not on the chance of his not attacking, but rather on the fact that we have made our position unassailable.
Sun Tzu’s The Art of War

As Sun Tzu teaches, you must plan for mistakes, issues and ensure you have a mitigation strategy from the earliest stages of the project. Mixing my metaphors further, if you only build a strategy based on what you can see of the iceberg, the vast majority you can’t see is almost guaranteed to foul you up.

In an IT project, there are several methods for mitigating risk or planning for failure, but the main ones include:

1. well documented design – a good design will call out the unknown and risk areas such as details you can not decide until actually begin construction/integration
2. schedule padding – this is often viewed as a bad thing, but it’s not as long as the team doesn’t abuse it. Do not do it blindly, but pad the risky tasks that aren’t fully defined. Also, practice complete transparency here. Mitigating risk is a good thing that your management and customers will appreciate
3. frequent status meetings – ok, I hate meeting just to meet, but well organized, focused meetings can be very useful for early identification of risk. This allows the leads to more quickly create mitigation plans

You can never quantify or predict what will go wrong in the future, but if you build a plan that only assumes success, you are guaranteed to fail. So, hope for success and plan for failure.

Then I became a manager. I hated 1:1′s. I wasn’t comfortable micromanaging. It felt wrong. I held them, but canceled them at the first possibility. It wasn’t like I didn’t have a weekly team meeting or project reviews. If I saw a need for a corrective action, I didn’t wait for a 1:1. I stopped by their office, asked their opinion on what was taking place, made suggestions on corrective actions. If I saw them do something well, I praised them on the spot.

It wasn’t until I changed managers a few times that I finally found out what a 1:1 was for… He and I had been peers before he was promoted and took over the department. I knew when I saw the calendar entry pop up for our first 1:1 that it would be awkward. But it was eye opening. He started by explaining that these weren’t for him, they were for me. He wanted me to set the agenda. He felt he had plenty of opportunity to discuss project status, knew what I was working on and was happy with the communication that was taking place. I didn’t know what to do. He helped me out with some suggestions, but told me he expected me to start personalizing it to meet my needs.

Eventually, it became conversations around my professional goals, challenges I need advice on, etc. I started following the same practice with my direct reports. Once I realized they weren’t for me as their manager, but for them, I began looking forward to them. The pressure was off. I could relax, find out what they thought was important. They became coaching and, in some cases, mentoring opportunities.

A few years later, I find that each 1:1 is different. Some people want to give me a blow by blow update on what they’ve accomplished. Others want to talk about their careers. Most want to meet every other week (I’m a firm believer that weekly 1:1′s are overkill – I like to create impromptu ‘drive-by’ situations), while a few only want to touch base briefly once a month. My only rule is that they think about how they want to use the time and come with an agenda. The only addition I place on the agenda is that we discuss their quarterly goals (not specific project tasks).