Tag Archives: manifesto

Why Your Process Needs to Be Adaptable

Coaching tips,

Last week I had 3 customer meetings the same day, with 3 very different customers.

The first meeting was with a conservative client who we had been talking to for weeks as they asked 1000′s of questions about our product and our process for implementing it, supporting it etc.  All fair questions in my opinion, and some of those questions were “what happens if 500 people all do ‘feature x’ at the same time?“.     That told me they were more risk adverse and liked the perceived safety of well thought-out plan. They also got into some low-level details that I didn’t think mattered at this stage, but I was happy to indulge and answer their questions.

The second meeting was with a customer who is a lot like me.  Likes action, speaks her mind, doesn’t beat around the bush and moves very quickly.  She hand-drew the UI she wanted for her iPad app, emailed it to me and within 15 minutes we went through all 15 or so screens to finalize the flow and information we would display.

The third meeting was with a customer that we had recently launched an iPad app for.  We were starting phase 2 and were talking about some of the updates we had made to our platform.  This meeting was somewhere in between the other two.  We went into the right amount of detail, IMO, and wrapped up somewhere between the time the other two meetings took.

In all 3 meetings, we reached tangible action and in all 3 meetings I adjusted my tone and language for each situation.  In the second meeting, for example, I had no problem being blunt and direct because I knew that customer would appreciate that more.

I have a “process” for how I build our apps, what details I need from the customer and I adjust that based on the customers needs.  If they need more documentation for some reason, I’ll make it and re-use it for the next customer who requests it.  If they want to work with hand-drawn mockups, I’ll work with that.   If I feel managing them through the building process will be like herding cats, I’ll change my language and use phrases like “I’m concerned if we don’t decide on X we’ll risk missing the date you want the project live”.   I find that’s a helpful way to ground customers who are spinning off into ‘what ifs’.

As I was driving home from work I had an ‘aha’ moment from PSL about that day.  I remember near the end of PSL, Johanna Rothman had stuck around giving a few of us more advice about how to bring PSL back to work the following week.   We talked about how to use what we learned about types and temperaments as a way to understand ourselves more and how we intake and process information from other people.  MBTI isn’t a theory used to label people, it’s never about that other person, it’s about you.   I found that having an understanding of myself helped greatly in these meetings.  It also helped me ‘get a feel’ for how I could change my tone, messaging and questions I asked for each situation.  Never once did I try to get them to change in order to fit them into a process.

I believe what I described is pretty basic customer management and this translates to whatever software development process you use.   The first Agile Manifesto value is ‘Individuals and Interactions over Processes and Tools‘.  Use your process as a guide, not a set of rules that you can’t deviate from.  I remember consulting for a company that had been using Agile for years and I was shocked how many times I heard “we can’t, our process is…“.    You’ll build a great deal of trust with customers by having an adaptable process and that will make it easier to live by the other 3 values.

The key is to find balance, if you’re working on a feature that has many unknowns, plan more frequently and in smaller timeframes.   It  may sound counter-intuitive but in that case, you’ll want to plan less.  Sometimes you’ll need mockups or more detailed requirements, sometimes you might not need any at all.  Once you understand the process you are using, you’ll be knowledgable enough to break the rules, when it makes sense, and realize that software development isn’t a linear and repeatable process like building toasters on a manufacturing line.

Deliver Software, Not the Plan

Coaching tips, ,

I attended the Rally webinar about Keys to Successful Release Planning and heard a great comment from the presenter:

“Focus on delivering software, not the plan.”

Think about that for a minute, it’s ok, I’ll wait.

<insert jeopardy music here>

One of the myths of Agile is  that Agile teams don’t plan.  Agile teams focus on ‘planning‘, not ‘the plan‘, there’s a difference.  Let’s face it, the software development industry moves quickly and for the lack of a better phrase it would just be completely nuts to plan out exactly what we will deliver for all of next year.  Sure we’ll have a loose plan for what we want to deliver based on what the company strategy is, but are we going to follow that plan into the ground or adjust to new information?  Remember, the Manifesto says we value responding to change over following a plan.

So what’s good about a plan? Everybody loves a plan.  Plans are what keep people accountable, plans are what make us comfortable, plans help us feel secure.  Once you have a plan, you have set expectations.

So what’s not-so-good about a plan? Once you have a plan, change is difficult due to the perceived chaos change introduces.  Once expectations are set, traditionally changes aren’t effectively communicated to all those who should know about it.  Plans can be used to place blame when things don’t go according to the plan.

At the end of the day we are delivering software, not a plan.  In the end when plans change and chaos ensues, the issue isn’t the plan, it’s communication.

Case in point, in our iteration 6 demo one of our stakeholders asked “I thought you were doing XYZ?”  Was it the stakeholders fault?  Nope.  Was it the outdated roadmap the entire company was looking at?  Nope, ok, maybe partially.   It was a communication problem.

We had failed to effectively communicate to all of our stakeholders the change to the plan.  Sure this change happened 3 months ago and sure this particular stakeholder hadn’t come to any previous demo but once this stakeholder had the plan in his hands 3 months ago,  his expectation was come hell or high water, we will deliver the plan.

This creates a vicious cycle, especially in organizations that lack trust.  If the team doesn’t deliver the plan, the business instinctively responds with more process and more control.  Obviously the team can’t be trusted if they can’t deliver on this simple plan we agreed to right?  People, especially teams, become deflated, morale sinks and people co-operate less for the fear of the ramifications of the decision to change the plan.   Another nasty side-effect is the battles about scope-creep.  We become so focused on arguing about what’s in-scope and what’s out-of-scope we lose sight of the fact we’re delivering software.

So how do we get out of this oscillating cycle?  First of all, communicate better.  Help the business, or folks having difficulties adjusting to Agile, understand why Agile teams plan the way they do.  Listen to their concerns about why they want a committed roadmap for the next 3 years.  People are often resistant to change but it’s important to not confuse their response with resistance.  There is always an underlying reason for why people respond the way they do, keep the communication open and move forward.  Of course you won’t always agree, but listening to others concerns is a great place to start.