What’s Your Problem?

As every manager knows, you have two types of people on your team: Problem Bringers and Problem Solvers.

Problem Bringers

Problem Bringers have a great talent for identifying anything that’s wrong and needs fixing. They spend a fair amount of time looking for issues to package up and drop right outside your door. “I don’t know if you’re aware of this, but we have a real problem here…” is how they call attention to what you or someone else needs to jump right on. They can tell you in detail what the issue is, how long it’s been going on, how bad it’s gotten and, most importantly, how much trouble it’s causing them.

While Problem Bringers have an eagle eye for recognizing problems, the one thing they want no part of is doing something about them. Just try asking, “So, how do you think we could fix that issue?” My experience is they’ll almost always do one of the following things:

  • Get all huffy and point out that the problem is not their fault.
  • Recommend you or someone else on the team take care of it.
  • Begin cataloging all the other things they’re busy doing that prevent them from tackling the issue.
  • Look confused, back away, and pretend they didn’t hear you.

The Problem Solvers

Problem Solvers

On the other hand, Problem Solvers just take care of whatever needs fixing. When they identify a problem, they don’t waste time getting frustrated because no one is doing anything about it. Instead, they jump in and take ownership of it. You’ll often hear after the fact, “I had this roadblock pop up on the project, but here’s what I did about it. I hope that’s okay.” Are they kidding? Of course it’s okay—you wish all your employees did it that way. Even if they don’t know how to deal with something, they at least take the time to investigate and come up with some ideas for how to resolve the issue before they even tell you about it.

You know someone is a Problem Solver when you regularly find out about problems after the fact that he or she has resolved without any input from you.

You know someone is a Problem Bringer when your initial reaction to seeing him or her walking your way is a sinking feeling followed by the thought, “Oh, great. What now?”

It’s a good idea to assess where you are vs. where you need to be when it comes to your current team. Because surrounding yourself with one group and not the other can really make a difference in what you accomplish as a manager.

What experiences have you had managing Problem Bringers? Have you found a way to turn them into Problem Solvers? We’d love to hear your ideas.

About the Author: 

Janna is Vice President of Client Services for The Berke Group, where she leads their education initiatives and serves as their key client advocate.  Berke provides powerful assessment software that measures personality, talent, and intelligence and helps companies hire the best people.  Janna develops Berke’s  learning programs and provides both on-site and web-based management training for companies and individuals. She also writes about people management strategies, trends and best practices.

Posted in: 
Hiring Manager

Agile Project Management—The Clarity of Transparency

I’d like to begin this post by trying to describe some of the anti-patterns or characteristics of non-transparent work behaviors. This list will probably not be complete, but it should give you a sense of the other side of the fence.

  • There are several show-stopping defects in your current code base and you are either not tackling them with your best people or hoping their intermittent nature won’t surface inopportunely before general release. So essentially you are throwing a few bodies at the problem and hoping nobody truly notices.

If you’re transparent, you must acknowledge and manage quality—being willing to “stop the line” if things aren’t’ right and fix them. This takes courage and commitment.

  • Your team is working incessant over-time; making more and more mistakes as they go—daily adding rework and risk to the project. Not everyone on the team seems to think you’ll miss the deadline and nobody in management is willing to “admit defeat”, so all project status reports are still shown as GREEN and the project as “doing fine”.

If you’re transparent, you resist the lack of character & courage to tell the truth about project state for fear of ramification. Instead you routinely tell it “like it is”, and look to make healthy adjustments from “where you are”.

  • You began this project three months ago and the business stakeholders were ecstatic when you kicked it off. They even threw a party. But then they “went away” and you haven’t been able to reconcile numerous requirement clarity questions with them along the way. You’re having your release demo tomorrow and they now all seem to have the time to come and check out the results. The “Great Reveal” is at 3pm and it should prove to be exciting.

If you’re transparent; folks need to be willing & sufficiently engaged to look in and react, in real-time to the good AND the bad of your project state. Willing to literally get in the game with you and adapt the project forward— guiding the project towards success.

  • You are struggling to deliver the fixed set of features in your latest release. You know which features are at risk, but can’t have the discussion to drop any of the features because the business insists that ALL are 100% required. As a result, you slipped the release date five times and eventually delivered a release with low quality, 14 weeks later than your initial commitment. Oh and did I mention that seven of the most critical features were missing?

If you’re transparent, you acknowledge adversity, look it square in the eye, and make adjustments to your goals. You do so from a position of business value and priority—realizing that everything isn’t equal. You realize that delivering something has great advantage over oscillation.

Now that you have an idea of situations and responses that can be linked to transparency, let’s delve further into more definition.

What is transparency?

From my perspective, it’s the honest and open dialogue about the current state of software development within a project context. There’s no telling you what you want to hear. No providing misleading or hiding information. I have the phrase “It is what it is” running through my brain whenever I think about transparency. What you do is show off all the gory details of a project for the world to see, digest and then constructively and realistically react to. For example:

  • Show your open defect counts and their rate of increase/decrease
  • Show your number of sprint escapes or rework that cascades into the next sprint
  • Show your project feature-set burndown for the release
  • Show your teams’ sprint burndown
  • Open the door to your daily stand-up meeting; ask the team not to filter anything as a result of attendee mix
  • Open the door to your sprint planning sessions
  • Open the door to discussions around what to do about your highest priority feature struggling to see the light of day
  • Run a company-wide retrospective for your latest release; taking feedback on all aspects

As an Agile Project Manager, you want to create situations where your progress is simply…transparent. In as many situations as you can. There’s the notion of Information Radiators in the agile methods that are intended to serve this purpose. They don’t comment on state as either good vs. bad. They simply radiate it for everyone to see, digest, and react to.
What does transparency create?

Transparency creates congruent conversations which drives congruent action. Imagine one of your teams having the following burndown chart for an existing sprint and your progress is right in the middle of the “danger zone”, where it’s obvious that “things” aren’t going too well.

What does transparency create?

What does transparency create? Agile PMTransparency creates congruent conversations which drives congruent action. Imagine one of your teams having the following burndown chart for an existing sprint and your progress is right in the middle of the “danger zone”, where it’s obvious that “things” aren’t going too well.

I’m actually delighted when this happens. And when a stakeholder attends one of our daily stand-up meetings and quietly listens to the discussions. When afterward, they pull me aside at the sprint burndown chart and ask—“We’re not doing so well right now, are we?” And I say no. But beyond that, she asks for more information and recommendations for corrective actions—what do we do?

Ah, now that opening leads into all sorts of prime conversational real estate:

  • We can and should start looking to jettison content from our sprint goal if possible. No, not the highest priority things, but the lowest. Additionally, can we reframe stories so that we can still hit the goal, with less scope?
  • Another point is to get the team engaged in the discussions. In fact, they’re behind in their own commitments for the sprint—so they need to be engaged. What ideas do they have about root cause and corrective adjustments? Can they move work around the team or attack things differently? Do they have any impediments that they want to disclose?
  • Does experience of the team come into play? Is the wrong person attacking this work? And would an assignment change, shifting work around, help us to recover?
  • If it’s related to defects, is this an ongoing trend? Is it related to exhaustion or excessive overtime? Does the team lack core, requisite skills? Or domain experience? Or are they simply sloppy in their professionalism?

You see, transparency leads us away from obfuscation and into clarity. It’s all about delivering to our goals. If there is a risk, then how can we deliver the most value becomes our mantra. Short-selling quality is not an option. Working like dogs is not an option. Making scope compromises based on early detection and early, mature, and considered reactions to reality is the only option.

Reactions that are made tightly partnered with your business stakeholders in a non-confrontational, but truly collaborative fashion. And Agile Project Managers do everything they can to effectively guide their project stakeholders & teams in THAT direction!

About the Author: 

Bob Galen is the Director, Agile Practices at iContact and founder of RGCG, LLC a technical consulting company focused towards increasing agility and pragmatism within software projects and teams. He has over 25 years of experience as a software developer, tester, project manager and leader. Bob regularly consults, writes and is a popular speaker on a wide variety of software topics. He is also the author of the book Scrum Product Ownership – Balancing Value from the Inside Out. He can be reached at bob@rgalen.com 

Posted in: 
PM-Agile

Putting America Back to Work – President Obama’s Town Hall with LinkedIn.

Putting America Back to Work – President Obama’s Town Hall on Jobs and the Economy with LinkedIn.

President Obama spoke to the LinkedIn online community and a local crowd at the Computer History Museum in Silicon Valley yesterday.  The President spoke about America’s driving spirit – entrepreneurial, forward thinking, optimistic.  The hope he projected was reminiscent of his campaign trail speeches.  He wants America to succeed and progress, and he reminds us, “When America has moved forward, it is because we have moved forward together.

President Obama and LinkedInHe also spent much of his time promoting the American Jobs Act, and his concluding remarks included an appeal for Americans to tell their Congressmen that they support the American Jobs Act.  He believes that the majority of Americans believe in the tenets included in the Act, and he wants us to buy in, and to persuade our Congressmen to buy in.

Regardless of your political views, you can imagine that speaking in Silicon Valley left the President answering questions from several IT professionals, and more than once he touched on a problem that many unemployed IT professionals encounter – maintaining recent skills.  He echoed what many in the industry have said before – the most important thing an unemployed technical professional can do is take classes, or online training, to keep your skills sharp.

To paraphrase President Obama’s response to one unemployed IT professional:  Right now your challenge is not you; it’s the economy as a whole.  Your challenge is making sure you hang in between now and when it picks up. 

Whether you’ve found yourself recently unemployed, or if you’re experiencing long term unemployment, look into programs that will help you get into classes and/or certifications to keep your skills current.  You’ll make yourself more marketable, and when the call comes, you’ll be ready to go.

About the Author: 

Kathryn Smith is a Technology Recruiter at MATRIX Resources and has been recruiting for over a year. As an Economics graduate and prior Economic Research Analyst, she continues to follow the labor market and emerging technologies closely. Look for future blog posts about the recruiting process as well as labor market outlooks.

Posted in: 
Job Seeker

Become an Informed Executive - This Year at #IOD11.

Trustworthy information is critical in enabling organizations to compete in a global economy where the pace of change is unprecedented.  The data flowing through every aspect of the global economy is growing at an astounding rate.  Studies estimate that enterprises globally stored more than seven exabytes in 2010 (estimated to grow at 40% per year). And yet, the majority of CEOs studied feel ill prepared to handle the growing complexity and use of this data for a competitive advantage. 

Business Intelligence Performance Management (BIPM) programs have become critical factors in driving decision making in both day-to-day tactical activities as well as long-term strategic planning.  Leading companies are leveraging data as an asset to drive value, create competitive differentiation and increase operating margin.  Those who do not will be left behind.

Executives must leverage their organizational resources to identify innovative ways to create value for the business.  Pioneering organizations (corporate and non-profit) are using data to identify and develop new propositions to create value across operating functions.  However, companies that rely solely on IT to deliver ideas and execute will miss the mark.  We are at an inflection point where business process, technology trends and economic factors are accelerating and converging.  As a result, an effective BIPM program requires complete synergy between business and IT.  It requires moving beyond silos to an integrated environment and a holistic view into the many aspects of successful BIPM programs.  The CEO is looking for ideas and people that can present a compelling case for change.  Executing on those ideas will bring value to the organization and success to the teams involved. Over 90% of CIOs studied said they would lead or support efforts to drive real-time decisions and take advantage of analytics in order to support the executive imperative.

S.M.A.R.T WorkshopThrough our work across various business functions, we have distilled the core aspects of each BIPM program down to a simple framework that  can be used to communicate and align teams towards success - S.M.A.R.T. (See Figure)

When an organization aligns the business around these core components, the probability of BIPM program success increases dramatically.  However, since organizations tend to operate in silos, groups do not always interact in an optimal manner, and the teams rarely have a good perspective on what is important to other parts of the business.  Ideas come up across groups, but these ideas need to be shaped into a viable business proposition before they are presented to the Executive Team.  As consultants we continually need to coach clients on how best organize their ideas and concepts into a framework that and will capture the attention of the key project sponsor, and instill action to move forward.  Executives have repeatedly stated that this is a gap in corporate capabilities.  Hence, we developed the  S.M.A.R.T. Workshop with a focus around our core expertise in BIPM as a result of our work with both global and mid market businesses. 

The S.M.A.R.T. Workshop is designed to allow Senior Executives, Operational Management, IT Leadership and staff to collaborate and gain an understanding of the priorities and constraints involved with the needs of the business.

During the workshop, teams collaborate around the S.M.A.R.T. framework with a goal of obtaining a holistic view of the definition, appropriate use, delivery, and management of information assets in order to enhance business insight and drive business performance.

To date, over 200 attendees have come prepared to solve problems and collaborate with peers to discuss BIPM strategy, the use of metrics and analytics, reporting and scorecards, and supporting technologies.  They have left with a better perspective on what it takes to bring the many BIPM moving parts together and have improved their skills in building and presenting a 'case for change' to the management team.

This year at IBM's Information on Demand (#iod11) conference, October 25, 2011 in Las Vegas, myself (Greg Boyd) and Kwesi Oseitutu will be conducting two workshop sessions.  It's a valuable experience to network with your peers.  If you will be in attendance at IOD, feel free to join us for a session.  To register, click here.

About the Author: 

Greg Boyd has over 20 years of experience working with companies to solve complex Information Management issues. Greg, and his partner, Kwesi Oseitutu, designed the S.M.A.R.T Workshop to be a collaborative learning experience to help bridge the gap between business and IT. The session, which has been conducted with over 70 organizations across the U.S., continually receives rave reviews.

Posted in: 
Hiring Manager

SQL - Select Filtering (Part 2)

In the previous post, I covered the WHERE clause. You should now feel pretty comfortable limiting the number of rows you get to return based on the values in a column. But I'm sure you've already asked "How can I limit based on two different columns?" I'm glad you asked!

You can chain together your WHERE clause predicates by using AND or OR. If you've had any programming experience before you should be pretty familiar with these two. If you choose AND, then both criteria have to be true. If you choose OR, then only one has to be true.

Ok, let’s look at my Person.Contact table again, I want to look at all the Skywalkers in that table.

SELECT
FirstName, LastName
FROM person.Contact
WHERE
LastName = 'Skywalker'

OUTPUT

FirstName  LastName
--------- ---------
Luke Skywalker
Marvin Skywalker
Michael Skywalker

 

Looks like I have 81 Skywalkers in my Person.Contact table. Who knew, they were so prolific? Anyway, the problem with getting all 81, is I only wanted to look at Luke’s record. Since we know the FirstName and the LastName, we can combine them into one WHERE clause using the AND operator.

The AND operator

SELECT
FirstName, LastName
FROM person.Contact
WHERE
LastName = 'Skywalker'
AND FirstName = 'Luke'

OUTPUT

FirstName  LastName
--------- ---------
Luke Skywalker

Now we can see the one record we want. You can chain together as many criteria as you need with the AND clause.

The OR Operator

Like I was saying before, when you use the OR operator, if either of your two tests are true, then the result will be returned. Let’s take our last query and change the AND to an OR, and look at how the results have changed.

SELECT
FirstName, LastName
FROM person.Contact
WHERE
LastName = 'Skywalker'
OR FirstName = 'Luke'

OUTPUT

FirstName  LastName
--------- ---------
Luke Skywalker
Luke Foster
Marvin Skywalker

On my server, I got 133 results. This query returns every record in Person.Contact where the first name is Luke, no matter what the last name. It also shows you every record with Skywalker as the last name, no matter what the first name is. That's what OR does. It returns results that match either criterion.

Combining AND With OR

I'd like to issue a word of caution. When you need to combine AND with OR, please be aware of the order in which the comparisons will be made. This is where I introduce parentheses into my queries. Anyone remember "Please Excuse My Dear Aunt Sally"?

That can help you remember this: Anything in parentheses will be tested first.

When you start chaining together ANDs with ORs, you're going to see results that you don't expect to see. In those cases really study the logic you're sending to the SQL Parser. Should two of them really be considered at the same time?

Let's look at a contrived example. Show me all the products that are yellow or green and cost less than a dollar. You have to really consider that logic. Do you want to see all items that are yellow and less than a dollar and all the items green and less than a dollar? Or do you wish to see all items less than a dollar that are yellow or green?

SELECT
Name, color, ListPrice
FROM Production.product
WHERE
color = 'yellow'
OR color = 'green'
and ListPrice < 1.00

OUTPUT

Name                    color   listprice
--------------------- ------ ---------
Road-550-W Yellow, 38 Yellow 1120.49
Road-550-W Yellow, 40 Yellow 1120.49
Road-550-W Yellow, 42 Yellow 1120.49

The lesson I want you to pick up here is that you have to look at your results and compare them to the logic you intend the server to follow. If your results aren’t matching your intentions, look at the logic you’ve written. You may need to wrap some of your criteron together, so the server understand you.

The server after all is just a machine, and it will do exactly what you tell it, even if you’re not entirely sure what you’re telling it to do.

Conclusion

Logical operators are a fundamental part of developing queries. You'll have to define your instructions to the server is ways the server thinks are unambiguous. This can be a challenge, but with the proper training and patience, you can get the server to return the exact results you want every time. If not, you can always update your query and hit F5 again!

As always, if you have any questions send them in! I'm here to help.

About the Author: 

Look no further for expertise in: Business Analysis to gather the business requirements for the database; Database Architecting to design the logical design of the database; Database Development to actually build the objects needed by the business logic; finally, Database Administration to keep the database running in top form, and making sure there is a disaster recovery plan. Connect with Shannon Lowder.

Posted in: 
Development