Nov
18
By: Brian Bozzuto
11/18/08 5:00 pm CST

One of my favorite teachers in college was a former managerial consultant and our class enjoyed being regaled with stories of her former clients - a veritable who’s who of major companies - and the challenges they faced. I recall one lecture when she was telling us about reports and communications and how you need to understand the psychological impact they may have on an organization. She was working with a major department store in the early 90’s when the organization was in a steep decline. more »



Nov
16
By: Marjie Carmen
11/16/08 11:12 pm CST

Advanced Communication, Problem Solving and Team Facilitation skills!

The world around us is changing quickly. We have a new president, the economy is in rough shape, unemployment is up, financial institutions are closing, businesses are being stretched to do more with less and many are losing the battle. It seems everywhere we turn; the message is things are changing whether or not we want them to.

Good news ahead!

This is the right time and the perfect opportunity to focus on learning how to better influence positive change by sharpening the way we communicate with each other. We no longer have the luxury of time to allow miscommunication to continue. We need to acquire new tools and tips to add to those we already have. I have observed this from my personal experiences. What worked for me 10 years ago, 5 years ago, 6 months ago, might not work now. Techniques I used to solve problems, lead change, create teams were specific to the cultures and environments I was in. There was no one-fit-all style I could use and no one specific set of techniques I could repeat. I had to reach into my tool box and pick just the right ones for the specific environment and when I couldn’t find anything, I had to find more. Learn new techniques, acquire new tools, read more books, study more constantly re-inventing myself to keep up with the times.

The other skills to review are our Problem Solving skills. The ability to identify the right problems, work on solutions, refactor and repeat is more critical then before. Less people, less time, different problems, same old challenges.

We can no longer afford to see old patterns repeat, meeting after meeting without forward movement and most important, we must learn how to harness the collective knowledge of all as effectively and efficiently as possible. We’ll still make mistakes, but we’ll have new tools.

How can we do that if we don’t know how to listen, give and receive information in the most effective way? What if the way we thought worked isn’t working now? The only obstacle we face is ourselves. We all have the ability to do these things we just need to expand our toolbox for the new place we find ourselves in.

The brightest and savviest CEO’s will embrace this period of time to restructure for efficiency and success leaving old behaviors behind and embracing the new. They will seek these skills and ensure it is a focus of training in their organizations.

The rainmakers will emerge. Be one.


Effectively Communicate

We’re all great communicators, well we are right?

Everyone thinks they are great communicators. Every resume says so.

We don’t pay for these courses, many never take them or pick up a book yet on nearly all performance review forms there is a section for communication skills and nearly everyone has areas to improve there. It’s puzzling why we don’t support these courses.

If we’re all so good and we don’t need improvement then why is it we see these patterns repeat and repeat?

  • Meetings start late, run over and the same problems come up week after week
  • Decisions to choose methodology or practice are delayed resulting in odd combinations that render little to no noticeable change in results
  • Interviewing skills are lacking
  • Interviewer skills are not productive
  • Hiring decisions take too long and the list goes on and on

Have you ever heard, “she understands me” or “he gets me” but you don’t? We fight with our kids, our friends, our spouses, our colleagues while we get along fine with others. What is obvious to me is not obvious to you and I can’t seem to get you to understand why but why is it what I am saying is obvious to someone else? If we’re great at communications, why is this? The facts could outweigh our own perceptions of our skills and perhaps those around us.

Tempermants and Interactions

How can we get better? Study, learn, adapt and repeat.

I learn by studying models. I might suggest trying to learn the MBTI model, combine it with the studies of the Satir Interaction model and together with coaching and facilitation understand how we communicate, how others communicate and more important, how this plays into how you receive, perceive and respond to information. Out of this comes a far greater chance of gaining and improving problem solving skills and influencing skills.

You can observe communication patterns everyday in the workplace. During meetings, when one or two people always take the lead or talk the most or are the loudest while some people say nothing? Why is that? Some people can talk all day about the possible factors as reasons for problems while others absolutely need to have a decision made after several go arounds of reasonable reasons. Why? Some people care more about how people are feeling and reacting in a meeting as they are observing this while other people don’t even notice that these people are in the room.

A basic outline to get started

· Learn advanced communication skills based on a model that fits for you and set team norms so that time is not wasted with miscommunication. These will be skills people can use forever to increase their overall personal effectiveness as well as their effectiveness in their roles

· Learn how to lead teams through problem solving sessions where the team concludes what their real issues are utilizing a series of advanced techniques in facilitation and coaching. If they are not seeing something you can see as an outside observer, provide that feedback

· Lead some retrospectives using methods that work during problem solving sessions to push teams out of stuck positions and move them towards making decisions and solving problems

· Let a couple of weeks pass as the teams work with these new skills

· Meet again and let the same teams go through a similar exercise where you can lead them through focusing on some potential solutions. Help them organize and provide a structure through which they can focus their efforts with a follow-up plan and time and actions that are time-boxed and result-oriented

Conclusion

People, teams, organizations know what they need to do. It’s the effort between knowing and doing that stops them. We all fall into old patterns, even when we know better and we all know better. Sometimes we’re just too busy keeping the business running to stop and reassess. Sometimes we realize that being on the inside of an organization is already putting us in a position of ineffectiveness and bias. We know what we know but for reasons we don’t, we’re stuck. And sometimes, we simply have not had time to pick up the vital tips referred to above because we were focusing our careers in other directions be it technical or management. Simply, we need to constantly add to our toolboxes and these days, even more so.

Being here is not the problem, how you got here – not terribly important. Staying here – is not an option.

It’s helpful to have an outside facilitator/coach come in that is unbiased and only there to assist. Sometimes it’s the only way to realize that breakthrough you’re looking for.

For organizations that are intent on making impactful changes that help now, contact us!



Nov
13
By: Mike Dwyer
11/13/08 1:56 am CST

I have spent a good portion of the last 15 years trying to go back to the future. For the first 15 years I worked in companies where Quality was paramount and their common approach shaped my thinking and actions. Names like Fisher Price, Parker Brothers, Eastman Kodak, Wang Word Processing, speak to the power and importance of quality. With their respective demise I also learned another important lesson about quality. It is not just about how well the product is built. It is the value the product adds to a customer’s quality of life that separates a fad from a staple. This, it turns out, is the one item I have found that moves business and management to understand the importance – to their success – of having quality at the front of the train.

The most frustrating part of QA and test for me is investing huge amounts of time and care into assuring the quality of some item that has no value. I say this not as a QA manager, or Test Manager (I have been both) but as a Developer, Engineer and stockholder. After all the core specification for anything Agile is Value. In Theory of Constraints terms, Agile QA is about what Glodratt’s calls the inspection of parts before working and ensuring it is to specification otherwise you are wasting people’s skills on refining trash.

Today, what are we doing to assure we are working on the most viable item of value we can produce? From where I sit, we seem to think that magically all things we touch must have value otherwise they could not exist in our world. What a load of hooey. Bottom line, if you are working on something that contributes nothing to the value of the product then you are wasting your own time, your company’s resources, and your customer’s faith in your product.

Let’s look at the role of QA can play within the context of the Agile Manifesto and Principles.

  1. We need confidence that what we are doing has value and that we can trace that value directly to the Product Vision and the Organization’s goals.
  2. We need to make sure that we do as little work as possible to produce the value in the product. This is not saying that we do a slacker’s best. To the contrary it is saying we only work on those things we have a dead certainty as to what it is we need to produce in order to have it accepted as DONE.
  3. It means that we have a way to delay to the last reasonable moment those parts of the product that we are not dead certain of.
  4. It means that we have a way to identify what the value is before the part enters our plans.
  5. Finally it means that we have an early decision and definition of what value the part brings to making the vision a reality.

The role of QA in Agile then is to be the Product Owner’s trusted advisor on assuring the Value of the Product moves in continuity from the vision to the customer’s compliments.

So what is to happen to test? If QA has a new role in Agile, Test has a new life. If the developers are aware of what the product is supposed to do then, in small projects/products test is already a teacher and shows developers how to develop tests that automate well; it is also a mentor to the ScrumMaster and the product owner giving them confidence on the coverage of the product. Now test has the chance to assist the Product Owner in judging the doneness of a delivery. If this in place when larger projects ramp up, Test actually gets to do its job.

As the product, project, scales teams deliver acceptable components along with the automated acceptance tests used to assure the component is DONE. These become part of the regression sanity smoke tests and free up the scarce test professionals to exercise and explore the interfaces and operating parameters of the product.

Can Test now move to iterations, scrums, and fast delivery? Interesting question and the early results are encouraging. More later.



Nov
04
By: Brian Bozzuto
11/4/08 2:32 pm CST

Recent events allowed me to catch up on light reading and I found myself going through “Sway - The Irreresitable Pull of Irrational Behavior” by Ori and Rom Brafman. The book is a generally enjoyable light read, but it delved into one topic I found very fascinating: irrational loss aversion. more »



Oct
29
By: Marjie Carmen
10/29/08 11:59 pm CDT

When your CIO thinks everything is fine, but you know it isn’t.

(How many times have we all seen this or experienced this situation?)

Agile allows everyone to win.

John the CIO thought everything was running smoothly, not perfectly but customers had stopped complaining and products were shipping on time for once. Re-org after re-org had finally brought some results. The developers/testers/project managers and business analysts were happy, or so he was told by the V.P. of Development to whom all departments reported. Everyone was solving problems and working together in the open and bright space. Disciplined process and structure were in place and demonstrated during executive and shareholder meetings using sharp power point presentations. Documentation, process and procedures were stored in shared repositories for all to see. More eloquent documentation you could not find.

Everyone agreed improvements needed to continue but the executive management team was elated.

While it was true, products were shipping, what he didn’t know is that people were working in excess of 50 hours per week and more. They were now working nights, weekends and sometimes over night. He heard about the video games, pizza and food being brought in so he assumed, everyone was being taken care of. What he didn’t know…Changes were made hours sometimes minutes before going to production completely bypassing the QA team and being looked over by the B/A’s or sometimes just the developer. Negotiations with clients were made on features so what he thought was being delivered months earlier according to a ppt presentation really wasn’t but the VP had already smoothed that out with the client. To those above, it “appeared” that the team shipped all features, defect free, on time but what the teams knew, particularly those closest to the code and deployments, is that they shipped some of the features, not well tested, and held their breath followed by other negotiated smaller production deployments all without the CIO’s knowledge! Everyone knew what was going except for management that was carefully “managed” out of the information loop.

While people on the teams knew what was happening, bringing it up to the PM’s or VP singled them out as non-team players and before they even knew what had happened, they were removed from the teams. Eventually, everyone stopped talking and trying to make things better. It was easier and less risky to simply comply and stop pointing out the obvious flaws and potential serious harm this vicious circle was causing. The risks the company was taking without knowing it as well as the clients. Employees observing this were losing respect for management and the prospect that things would get better. There was a growing concern that it was important to keep up the illusion of success. Technical debt was building and building to an untenable point until products completely failed to be deployable without multiple code patches and increased  manual testing cycles. Eventually it was not possible to hide the crumbling product infrastructure.  Regardless of how hard people worked, how fast the coding went or how much the testers tested, the product could not be  stabilized and it was not scalable . Nobody wanted to hear, we told you this would happen a year ago or even last month. The CIO stood up and took notice but wanted action, not excuses. Again people rushed to FIX IT instead of stopping to figure out, what caused this problem and again, went into the immediate hectic circle of HURRY, WE HAVE A PROBLEM, FIX IT, TEST IT, SHIP IT, HURRY, FASTER, FASTER, And FASTER.

Oh problems were identified; you know the story, the usual ones.

· The project managers, were not quite right for the team but instead of removing them, we’ll just add more

· Testing is too slow and it’s all manual

· We need to split development into maintenance and new development

· We need more people in general, that’s it, we’ll put a few senior people on the project and several really expensive consultants, they’ll fix it right up and kick everyone back into shape.

· Oh it’s just the testing teams fault anyway, lets fix the testing process by designing process flow diagrams and making lots of templates. They are supposed to assure quality right?

Needless to say, nothing changed. But the CIO thought it was all fixed up because the product started shipping again. Hmmm.

The team became fragmented and completely demoralized having been told everything was better. Nothing changed. The patterns of behavior that caused the problems simply repeated but the appearance was that the product was “stable”.

To the teams, nothing changed except they now had to report status to more people and defend their efforts instead of improving the process. Because the teams were split into maintenance and new features, they now had less people doing more work and the code defects increased thus increasing testing time.

People started to leave. Those who stayed dragged themselves in. The team had no spark and no reason to go above and beyond.

What agile could have done for this team?

Rule 1. Agile really does require top down support. Whether it’s the CIO or the SVP, it requires the most senior sponsor to support it completely.

Rule 2. Agile is transparent and as we all know, you have to face the ugly and deal with it, as Brian wrote, Step 1, Accept that you have a problem and be ready to deal with it, not cover it up or call it something else or “redefine success”.

Rule 3. Do not lie to upper management. You are not helping your CIO you are hurting your CIO and everyone else around you as well as destroying your credibility. Once people lose respect for you, it’s unlikely you’ll ever win it back.

Rule 4. People write software, test software, and organize plans. People are not resources, fte’s and contractors. Treat them like the people you thought you hired. They have brains, let them use them. Expect them to be brilliant and let them surprise you.

Rule 5. Stand up and say no. Not now, next iteration. Or, choose this OR that.

And many other basic concepts that Agile principals bring to the table.

People say Agile isn’t for everyone. But I wonder about that. Agile principal concepts are common sense principals that benefit everyone and every organization at every level. The fundamental guidelines bring out the very best and yes, not so great but gives everyone a chance to adjust. You find out quickly if you are doing the job you love or not. You’ll probably find that you’ll love your job more. Imagine bouncing into work pretty much every day so happy just to be there, with people you really like working with. Every day, just imagine…

And how much happier your clients would be and how much more productive the department would be.

And for executive management – imagine if you would, increasing your profits while driving down expense instead of spending more money to make money. Or instead of laying off people during a down economy keeping them.



Oct
29
By: Brian Bozzuto
10/29/08 3:51 pm CDT

I will not claim to be a religious individual, but an associate referred me to the Serenity Prayer - more commonly known as the Alcholics Anonymous prayer - as an effective mindset for a change agent. more »



Oct
22
By: Mike Dwyer
10/22/08 5:13 am CDT

I guess the most recent spamit was ‘that straw’. Some beltway bandit spending a lot of flash money to make it sound like they had ‘the answer’ for a mere $500 and your soul to some highly regarded, deeply entrenched, piece of BDUF tool. I do not doubt for a second they will be successful on this side of the chasm, because we all buy into the notion that if it is in a PowerPoint, then it must be true. What a line of preprocessed plant food comes out of those projectors these days. There was a time when the Agile community had stuff to say because everything that was talked about was based on experience not on flights of logical fantasy. Gee we even had a name for it - hmm how that go, Empirical versus Deductive analysis.

Today, those few nuggets of value have been tweaked, twittered, extrapolated and inflated to the point that almost any tool, software add on, metric that can be conjured is associated to all of the following slides.

  • Agile Priniciples
  • Agile Manifesto
  • Jim Johnson’s 2002 xp presentation
  • Anyone of a number of Scrum graphics
  • Scott Amblers data

And presto we have a new something or other.

I go back to Jim Highsmith’s comment regarding that there is more written about Agile than is known.

Right On Dude!

I guess that makes the people I work with on the outside, Everything we talk about is based on what we have experienced leading, coaching, and training. We know it works and we know how many errors we made finding this out.

AH, INSIGHT!

Perhaps there is a way to find out how much of the PowerPoint has Power by asking the presenter, how many mistakes it took to stumble across the gem they are offering. Hmm let’s see,  I can read about Mike Cohn’s stumbling into planning poker and points, just like I can listen to Ken Schwaber tell me about all the things he has done that did not work. If you want a good laugh, ask Jeff Sutherland or Ron Jeffries what surprises they have had. Dave Anderson still moans about all the things he would change in his book that he knows are wrong. Sanjiv Augustine too. I could go on and on with the people I know who have told me, written about it, but then I know I would forget someone like Jean Tabaka or Hubert Smits and I wouldn’t want to do that. SO all I can do is tell you what I remember.  Now wouldn’t it be nice if we had some record of all of our screw-ups?

Me? Hey…My most recent learnings are about how QA and Architecture teams impact large projects.  Most important finding is understanding how to get them acting like teams and not support staff.  Second most important finding is getting the rest of the teams to see their value early.  The mistake that led me to these learnings was assuming that Architects, QA and their management wanted them to act like teams after they said they did.  Key lesson learned.  Count the number of steps taken, not the words spoken.  Then again this may be why the straw really broke.

So where is the beef in all these presentations? Maybe we ought start asking.