Subscribe via RSS Feed

Tag: "software process"

What Taking-a-Hike Can Teach Us About Business

Hiking in autumn forestSomething Special…

This week I have something special for you. A guest post from one of my best friends. Dave Katauskas regularly shares insights that  make a huge impact on a team’s performance and success.  The story below has changed how he and I make choices within our daily work.

So, without further ado, I hope you enjoy the following blog post as much as I did.

Have I got a story for you!

Recently, my friend, we’ll call him “Bob”, and I decided to hike on the Ice Age Trail in Wisconsin. This was in preparation for our bucket-list-goal of walking a portion of the Appalachian Trail.  We knew any hike would be a challenge merely because we were non-active desk jockeys, 50+ pounds overweight and past middle-aged.  If you’ve ever seen the “before and after” photos in most health diets, we would be in the “before” picture.  I believe that sums it up.  Yet, we were determined and eager to get started.

Let’s get going!

On the first day of our 2-day hike, we set out on the Ice Age Trail to explore the wilderness and just enjoy ourselves.  We saw many great sights and regularly rested with food and water from our backpacks.  It was a great day with perfect weather.  All of the elements indicated that this day would run flawlessly.  In an eerie sort of way, this was strangely similar to the optimism and energy we have when starting a new and exciting project.

Knowing that this first leg of the hike was only a day hike, at some point in our journey we would need to turn around and track back to our car.  The morning went well. We felt strong, full of energy, sharing a great time on a beautiful day. The morning was going quickly and before we knew it, we reached the five mile mark. It was just after lunch that we started to think that turning back at this point would be smart. The second half of the hike would probably go slower.

After looking at the map, there was a ridge ahead that would provide some interesting views and a shelter.  Feeling physically able and still eager, I suggested that we squeeze in a few more miles before turning back.  Bob had a gut feeling that we needed to turn back because we may be reaching our physical limits.  He’s older and more out of shape. Of course, he was also being risk adverse. We all have a Bob on our project!

We clearly weren’t in agreement, so we discussed it a bit.  But without the definitive proof that we were actually reaching our limit, we decided to press on. His version of this story is that I convinced him to press on. We agreed to turn back at mile seven.

Around mile six, the path changed to a steep incline. I mean a painful, slow, incline.  But we made it to the top and to mile seven.  We felt great at arriving at the top of the ridge and rested on the trail near the tall grass.  Unfortunately, the view wasn’t as spectacular as we had imagined.  In fact, there was no view at all except for tall brush and grass.  But we still felt great at making it to mile seven!

So we took a break and decided that it was time to turn back.  The first seven miles were great so the next seven should be equally great…right?  As you’ll read later, we were oblivious to the fact that we were just short from the real “point of no return”.

It’s really not that much farther…

Well, about two miles into the return trek, we realized that we were out of water.  In addition to that, our legs and feet were starting to become very fatigued and sore.  But press on we did, not that we really had an option.  So, another two miles later (that’s 11 miles total for the geeks doing the math…like I just did) we were now becoming worn out. The storm clouds started rolling in, the wind was picking up and our flawless day was no longer looking so flawless.  We now had as additional sense of urgency to stay out of the impending storm.  Yet, we still had about three miles to go.  We saw the coming gloom, we still had plenty of trails in front of us and we were in pain. Talk about a “Death March”! (Have you ever experienced a software project similar to this?  Doesn’t this really sound like the beginning of a death march?)

Houston, we have a problem

The next mile became a struggle as our bodies were not actually equipped to deal with the demands which we had placed upon them.  This next mile was truly indicative of what the final two miles had in store of us.  Our legs started cramping, each step was actually painful and we were thirsty.  We limped along, well aware of each and every step. We genuinely weren’t sure if we would make it back to the car without some assistance.  (How many times have we committed to more than we can successfully handle?  Or actually know what we are really committing to?  On the plus side, we did know that were very close to needing to ask for help.)

And then it happened…

It became apparent to us that our short term view of what we thought was feasible became a decision that ultimately created pain, anxiety and the possibility of failure.  To add insult to injury, it started raining. (The “death march” continues)

After a long while, we finally reached our destination and found a covered bench.  We sat for a few minutes, then headed toward the car; a distant 12 feet away.  Limping and cramping is what I remember mostly.  After what seemed like an eternity, we walked from the bench to the car.  Now we just needed to get in.  We somehow managed to hold back the man-tears. Well, at least I did!

The residual evidence was apparent by our pampered and ginger walking around the office over several days.  A trip we’ll never forget!  (I’ve certainly been on projects where we limped across the finish line). Yes, pain is certainly one of the best teachers.

How we changed our views

A few weeks after our hiking experience, we were able to reflect again upon our journey and we noticed similarities around how making decisions for short term goals, or decisions based on lack of insight, can have significant effects on long term outcomes.  The decision to continue after mile five was clearly a bad decision.  We talked about the moment, that specific choice, which led us to continue on.

Then I thought about all of the bad decisions that I’ve witnessed and made on project work. But instead of the conversations centering on making a bad decision, we would state that it was just poorly executed. We would never challenge our decision approach or conclusion.  For this hike, our execution was fine; the decision was bad.

We then started discussing some of the decisions that we’ve personally made in directing business objectives and how some of those decisions created pain for ourselves and others.  And, in some cases, it established additional barriers for corrective action.

Our take away…

So, when making business decisions today, I now ask “how can we prevent this from becoming our 14 mile death march?” and “are we just kidding ourselves?”  I was actually able to put this into practice one day when our leadership group was discussing strategic staffing.

We knew that a decision to handle a short-term, non-bulls-eye opportunity would certainly hurt our capability to engage in an on-target opportunity in the future.  So, we had good discussions around that topic and looked at the varied perspectives with our eyes wide open.  We stuck with the strategic goals in spite of a small immediate win.  And since then, we’ve been able to apply that same concept to other growth challenges.

In addition to all of that, Bob and I have since hiked again.  This time, it included a change in our behavior, thinking and knowing our real capabilities.  It was a more pleasant experience.

So next time you have a tough choice and everyone is debating an approach, consider you may be at mile five of your hike, and sometimes, it’s better not to push the limits … because you’ll feel the pain for quite some time afterwards!

Solutioners are from Mars, Supporters are from Venus

Solutioners-are-from-marsRecently, I was asked to facilitate a team-building session for a group of directors.

It started with the normal “storming”, “norming” and “forming” that takes place when teams form. But then I had a huge AHA – a major breakthrough that, for some reason, has eluded me for quite some time.

In this meeting, there were nine directors who collaborate with each other across projects.  One of the directors, let’s call her Mary, began to explain how her team members were struggling to get their deliverables done on time. One particular customer, she explained, was beginning to get a little frustrated with their inconsistencies.  As soon as Mary finished describing her challenge, one of the stronger directors on the team, we’ll call him Joe, responded with his idea: “Well, can’t you work around the issues this way?  Shouldn’t this solve the problem?”

Joe continued to explain his ideas and approach.  He was talking for about 45 or 60 seconds before Mary deftly interrupted him and started explaining to him why she was frustrated and continued to explain her challenge in more detail.

Mary and Joe started talking at each other in  an extremely painful conversation.  At some point other people in the room said, “Hey guys, do you see what’s happening?  You’re talking at each other.  You haven’t heard one word that the other person has said.”

I think we’ve all experienced that.  We’ve all faced a situation when we’ve seen two people talk at each other.  Until they feel heard, they can’t hear the other person.  This is not a new concept.

We asked Joe, “What did you hear Mary say? Did  you hear her?  Because she didn’t think you heard her.”  In response, he effectively repeated some of the words that Mary said.  “So you’re having quality issues, and you’re missing your commitment so you’re getting beat up.”

We then turned to Mary and asked, “Is that what you said?” And she said, “No, that’s not what I meant.”  This went back and forth a couple of times. We’ve all been there.

And then I had the AHA!

Look at what really happened here.  Mary was sharing her situation.  She accepted ownership for the situation, and even though she was struggling a little bit, she wanted to work through it.

Joe loves solving problems. He wanted to share a solution. That’s his job! He immediately tried to help Mary solve this problem by offering her solutions.  But Mary didn’t want him to solve it for her.  Rather, Mary was just looking for people to provide support. Mary wanted to hear, “That’s got to be painful. Is there something we can help you with?”

Supporting vs. Solutioning

Many times when a colleague (especially a peer or direct report)  first shares a challenging or frustrating situation, they are  looking for your support.  They don’t want to be perceived as “giving up”,” out of ideas”, or relinquishing ownership for the situation.

There are other times when the individual may truly be asking you to step in and help solve the problem. They may feel they are in over their head. They need your help to find a solution.

What Joe did was fail to ask, “Do you need help? How can I support you?” He assumed the way he could support Mary was to give her a solution.  This approach made Mary feel insecure because she felt like Joe was going to take control of the situation and undermine her authority. It may have even made her feel stupid.

I think back to two leaders within my own company, both of whom have an affinity for solution mode regardless of what you want to talk about.  If you approach them to talk about how bad traffic was on the way to work, they don’t say, “Oh yeah, I ran into bad traffic too.”  They will actually say, “Did you consider taking a different expressway so you don’t hit traffic?”  They’re actually giving you alternatives to which you might go, “You’ve got to be kidding!  I’m not looking for alternatives! I know how to get to work.”

If you take two people who live in solution mode and put them together, they may struggle to understand who owns what and how to collaborative more effectively.  They both assume they personally own and are accountable for solving the problem because that’s how they’re wired.  Although they might have good problem solving skills, solutioners can make others feel like they’re not as good at their job or they’re failing because the solutioner had to grab ownership of the problem and solve it.

Unlike solutioners, supporters are not pulling ownership and accountability away from someone, which makes it safe to interact.

My current thinking is that if you take a solution person and a support person and put them on the same team, then they tend to really complement each other. You have to be careful, though, about putting two strong solutioning individuals together, especially if they don’t know how to throttle it or are unaware of what they are doing.

Bottom line, when you interact with your team or a colleague, I’d be aware if they are asking for you to be in support mode, or actually solution mode. This can help you be more effective at setting the team up for success!

Mars vs. Venus

I recently shared these thoughts with several colleagues who validated my thinking. One of them chuckled and said I just  summed up the book, “Men are from Mars, Women are from Venus.” (The bestselling the book that explains that sometimes all your partner really wants is for you to simply listen and be there for them.) This really made the concept hit home, and in fact, it helped me out at home too!

Do you have any solutioners on your team?

Change Control: Do You Own It or Does It Own You?

Change-ControlOver the last year, I have noticed a myriad of projects that begin to struggle once they begin the change control process. Doesn’t matter the type or size of project – they all appear to drop-the-ball when it comes to following the change control process. This pain surfaces not only in the schedule and budgets, but also in the lack of trust that builds between the business and technology teams.

I want to share some best practices than can help teams manage change control in a more disciplined format. In this first post, I discuss the key roles that should be involved in change control.

What is the typical change control process?

In a typical scenario, the business or project stakeholder comes to the table and says they want to change some functionality. This can be a change to something already built, or it could be a change to some requirements you have collected but haven’t implemented.

When asking for the change, the stakeholders typically want to understand any impact to cost or schedule before committing and asking you to “implement” or “deliver” the change.

What are the roles typically involved in change control?

In a typical change control process, the roles look something like this:

After a change request is submitted, someone is responsible for tracking and reviewing (think triage here) the change request. Acting as an editor, they review the change request and make sure the request is complete and without ambiguities. If there are any gaps or missing information, they go back to the “requester” or to the stakeholders to get the missing information. Obviously that’s pretty standard practice.

Next, one of the technology team members needs to assess the change request and determine what, if any, impact it will have on the current plans. By assessing, I mean sitting down and evaluating the impact of this change request against schedule, budget and staff. They may also identify questions for the stakeholders that need to be answered before they can complete their assessment.

This is where you typically have a “go to person” to do this initial assessing. This resource will typically be asking questions like:

  • Are we short on staff to handle this request?
  • What impact will there be to schedule?
  • What additional risk and/or dependencies does this add to our project?
  • Do I need any “specialists” or unique tools for this request?
  • And so on

The Changing Roles of Change Control

This is where I suggest including a larger team to do the change evaluation. Many of you may already use this approach. Kudos!

But for the rest of us, I suggest that we get a total view when assessing the impact of a change request. This means include a business analyst, quality analyst, etc. in the assessment.  I know there are some Agile teams that do this with all team members. Woohoo!

Why is this so important? Because one person probably can’t truly know the impact this change will have on other parts of the development or the development process.

For example the change may be trivial for the developer because it will take just two hours effort. However, the Quality Assurance team may have to rerun all of the regression tests, impacting the schedule by up to two days. A business analyst may actually look at the change and say, “Given the change, do we need to change three other things in the system so they’re all behaving consistently?” All of a sudden, the business analyst may have to modify other requirements. The dominoes may begin to tumble.

I suggest you make sure all roles on your team are included. It would be sufficient if a single team member plays multiple roles as long as this person knows they’re representing these other roles and thinks through the implication to other scheduling, staffing and costs.

Communicating Change

Make sure change requests are communicated across the entire team. Communication to and within the team is a discipline. Some of my experiences this year have reinforced that communicating changes isn’t optional.

Many team members think a trivial change (like a cosmetic change) doesn’t require informing the entire team. Again, this is NOT optional. It must be understood that we as a team are committed to each other and we’re not going to ”surprise” each other with changes requests. Once that is established, we need to educate the business, clients, and  stakeholders about our change control process and that they, too, must follow it.

Three Key Take-Aways:

  • If you don’t have a change control process, implement one quickly.
  • If you have one, but you’re not using the discipline to enforce it every single time a change comes through, you need to introduce that discipline to the team.
  • If you have a process and discipline, make sure that when you do the assessment all the roles are included (even if it’s one person representing the roles). Reinforce that the efforts of the QA, BA, etc.  have to be taken into consideration.

Do you have any other key best-practices for handling change control?

Are You Holding Back Your Team’s Success?

Damaged WallRecently, I hooked up with a friend and decided to do a 3-day hike on the Appalachian Trail.  As part of our preparation, we decided to try a day-hike in a State Park near our homes. We took this trial quite seriously and even planned how to mentally and physically prepare for the day hike.  I won’t bore you with the details, but the day we set out for the hike, we were pretty psyched.

We did 8+ hours on the trail, walking up and down paths that burned our legs by the end of the day. In the last hour or so, when were truly coming to our “wall of tolerance”, we kept repeating to each other how fortunate we were for all the planning. Had we not trained for this or lacked  the right supplies, we would have never lasted the day. Without a doubt, doing the day hike before setting out on our 3-day hike out east was the smart thing to do.

We focused on setting ourselves up for success.  And even with all the planning, we still learned a lot about what to do differently on our next day hike.

Learning From the Hike…

I can only imagine how painful that day would have been if we didn’t work our way up to walking an entire day of 13+ miles.  Or what would have happened  if we only had half our water ration (we used it all).  It would have been one embarrassing, failure of a hike.

This is a far more common scenario than any of us realize. When we start a new project, we typically overlook fundamental / key things that would set us up for success.  We may actually be holding our team back from the start.  And because of that, our team  may be digging out from this “team debt” for the majority, if not all, of the project.

Hold Up There

If you don’t agree, let me  give you just two common scenarios  that prove my point:

  • You  are starting a project. The  team is staffed and eager to move forward. The technical team is building out the environment and frameworks.  The Business Analysts are ready to collect and refine requirements, but are struggling to get the needed time and commitment from the business.

This not only causes churn for the BAs, but typically squeezes the schedule during the initial coding activities, with incomplete requirements and test plans.

  • Another example: You  are staffing up a project quickly so you can hit a set of aggressive dates for the business.  In doing so, you need to procure development environments and machines for all of the developers. However, due to an overworked infrastructure team, or worse, due to corporate processes, a third of the team may be without development hardware and tools while they wait for their stuff.

While they find other activities to do while they wait, this literally amounts to two or three weeks that could have been spent on actual deliverables.

These are just two common examples. You could probably start listing off a couple more.

What Are They Thinking?

So when this happens, what is management thinking? Are they intentionally setting a team up with an obstacle? Do they simply not care and assume we can adapt?

I believe that in most cases, management simply doesn’t realize that the team is being put into this position and the cost is more than a slow ramp-up to the project. I, myself, have asked teams to “see if they could work around some obstacles”, clearly not realizing the pain I may be introducing, not just short term, but to the long term success of the team.

So What Are We To Do?

I think one of the most basic things we can do in these situations, is to be vocal.  Share your clear and honest explanation of what the cost and impact is.  It is important to be accurate and not embellish or magnify the challenges.

For example, let’s say you have a project starting and are scheduled to collect requirements for the first deliverables during the week of 11/01.  Your  goal is to have the requirements and test plans completed by 11/15 so the developers can begin development.

If the business stakeholders are not available as needed the week of 11/01, I think it’s important to point out that development may not start until 11/22.  This is because the test plans won’t be complete and the requirements won’t be clear enough (the normal clarification won’t have happened).

If you can clearly show the cause and effect, management should take ownership of the cost and impact of these situations. If we can show them the cost in terms of dollars or in terms of schedule, then you have the best shot of setting your team up for success and getting management to own the challenges.

What do you think?  Have you found other approaches to help set teams up for success?

Software Architects: Hit the Ground Running

A New Look at Iteration Zero

Roadmap1How many times have you been involved in a project where leadership wants more architecture documents produced … but there just isn’t enough information to produce the documents? How about when leadership wants you to start coding the moment the construction phase begins?

While problems like this plague development shops, it doesn’t have to be that way. I believe that there’s a perfect plan (based on the Agile method of Iteration Zero — the phase that occurs after project definition but before construction) to make sure that when construction begins, coding starts.

Getting Out the Door

Imagine we are going on a journey. Whether our journey is a software development project or a trip to a new place, preparing for a journey should follow a process. Journeys that adhere to a process right from the start are much more likely to be enjoyable, problem free and capable of delivering better results.

Let’s say that we want to travel from Toronto to New Jersey. However, there are several things that we do not know about this trip. In fact, we don’t even know all the things we don’t know about yet. And, if we think that we know, we are only fooling ourselves. So what do we do? We pull out our map, and begin to look for the most direct route.

First we need to answer some basic questions such as “How will we get there?”, “When will we leave?”, “When will we arrive?” and “Why are we going?” Mentally, we start a high-level planning session to answer these questions. We eventually determine that we will be traveling on foot because the other options are just too expensive for our limited budget. We also determine that when we travel, we should arrive at our destination in about 30 days. We know that we are going to New Jersey to reunite with some old school buddies. When our visit is complete, we need to trek back to Toronto. This means that the total trip will span 67 days.

Then we start to drill down into the next level of detail. We need to cross Lake Ontario because if we walk around we’ll add another five days. We know that we are very good at swimming and coincidentally were born with webbed feet. We also know that we can swim across Lake Ontario in 3 hours. We plan our route across the lake and make plans to eat at Sally’s Diner in Buffalo, New York. We plan to rest in Buffalo and spend the night.

We then continue this level of thinking and planning as we travel through several states, rivers and finally over the Appalachian Mountains to our destination. After considering the potential for foul weather and our actual ability to make this trip, we realize that the trip will not take 67 days, but actually 84 days. This means that we need to start walking, or swimming, no later than the last week of March to arrive the first week of May. But, it’s already the second week of April. So, now we revisit the plan to include running instead of walking. Such is life.

Now that we have all of these plans, the next step is to actually physically prepare for the trip. The objective of this preparation phase (which takes an entire week) is to ready ourselves for the long journey and allow us to walk out the front door with confidence. It includes shopping for eight pairs of good running shoes, two pairs of hiking boots, a wet suit, some clothes, toiletries, a new back-pack and many other things. Next, we start a more detailed mapping of our exact route. We start conditioning our bodies for our impending, physically taxing experience. Without performing each of these activities, we increase the probability that we will be late for our reunion … or worse, not even make it at all.

We now have everything we need. We are ready to walk out the front door.

So, now you may be asking … what does all of this have to do with Iteration Zero and software development? The whole process described above is all about managing risk and approaching the goal properly. We have identified where we want to go and how we’ll get there. In software development, this can be thought of as business definition and understanding the business objectives. In the second stage of preparation —  studying a detailed map and the purchase of travel gear — can be thought of as Iteration Zero. This is where the team’s virtual assembly line is prepared. Finally, the third stage of swimming and running is the construction phase.

Next week, we’ll determine if our planning process was enough to have a successful journey (or development project) without stifling ourselves with too much complexity.  Process is supposed to enable, not disable.

What does your team do before construction to make sure that when construction begins, coding does as well?

Photo Credit: Scott Meis Photography

The Requirements Session Has Started. Do You Know Where the Business People Are?

When it comes to software requirements definition, engage the business … early, often and methodically

ClassroomLast week, I shared the results of a recent survey taken at a IT trade conference on the role of business in driving software requirements. Most of the people taking the survey stated that they consistently struggle in two areas: Connecting with the business and managing requirements throughout the development cycle.  They also admitted that at least part of their requirements process is broken.

This week, I’ll provide some thoughts on how to pinpoint some of these broken processes.

 

About to Start Requirements? Read this First.

During the requirements phase of a project, expectations and confidence run high. However, this is also the phase where lack of best practices begins to undermine success and worst practices rise to the surface.

Before you start the requirements phase of your next project, take an important first step by looking very closely at the “condition” of your people, processes and metrics.

Before you start the requirements phase of your next project, take an important first step by looking very closely at the “condition” of your people, processes and metrics. In his white paper, “Doing More with Less: Best Practices for Processes, People and Metrics” [PDF], Geneca Vice President and Managing Director, Bob Zimmerman, suggests asking the following questions to draw out areas in need improvement.

How do you work with the business?

  • Do all business stakeholders agree on the goals of the project?
  • Who owns defining requirements? Is this different from who owns “documenting” requirements?
  • How do you know when a particular part of a project is complete? How do you know when the overall project is complete? Does your team have this information and does it align with business objectives?
  • In general, after collecting requirements, are Change Requests introduced during the first 30% of the development lifecycle?

How do you track projects?

  • Do project status reports show progress in terms the business understands or is it in “IT speak” requiring translation for the business?
  • Is project success determined by being on budget? On schedule? Meeting the original business objectives and ROI? Which one?
  • Does your team use one internal project tracking report for status while the external report is different? Or is there a common report showing progress on the project?
  • Do business and IT team members typically have a consistent view on project status and health?

Are project roles and responsibilities clearly defined?

  • Is there a single person and role accountable for technical issues?
  • If you deliver a solution that works but is missing key features required by the business, is there a single individual and role that is accountable?
  • Are your project managers accountable for tracking progress and making project health visible? Are the responsibilities for this role consistent across all projects and project managers?

By answering these questions, you should be able to hone in on the areas of your requirements practices most likely to impact your ability to satisfy business expectations.

For successful requirements definition, the various players need to be involved in ways they might not have been before. If the business is not 100% committed to making this happen, even the most talented development teams cannot predictably give the business what it needs.

Organizations that hold the business stakeholders accountable to define their needs enjoy better results. These teams do a better job eliminating guesswork and rework, supporting change control, improving testing efficiencies and, most importantly, delivering exactly what the business wants.