The Agile BA: As an Agile Team...You Complete Me!

It’s a fantastic invention really.

It most likely was derived out of sheer necessity and in some cases desperation.  In many varied situations you can pull from it a wide array of tools which will get the job done when you need it most. It’s a versatile, useful, multidimensional asset; a must have for those who dare to brave the unknown.

Swiss Army Knife? No...but that’s kind of cool too.

I’m talking about the Agile Business Analyst.

I chuckle a little inside when I hear the contrast between some Agile ‘purists’ and Waterfall BA’s who live on different islands when it comes to the Agile team roles. On one side you have the self-proclaimed ‘agilista’s’ who evangelize the rainbow and lollipop world of completely cross-functional teams; with each team member well versed in development, testing, analysis and project management.

I personally feel that these individual folks got into their specific line of work for a reason. (Don’t get me going on this ‘BORG’-like scenario, where everyone can, at a high level, perform all functions when needed. I have yet to witness it in real life.)

On the other side you have traditional BA’s saying, “Where do I fit in here? I don’t want to code. I can test but don’t want to do it as a career. I like my BA job just fine but don’t want to limit myself to traditional methodologies. Where do I fit in the Agile world?”

Ladies and gentlemen, I give you the Agile BA.

Let’s take a moment to break down why this role is so crucial to an Agile team...

Imagine a far-fetched scenario where your technical experts aren’t real great personal communicators with the business representation (there’s that smile). Imagine another far-fetched scenario where Product Ownership isn’t 100% dedicated time-wise to the team. Throw in just for giggles the idea of an over-utilized QA team that is looked at as a bottleneck in quick to market delivery. Oh...and by the way...we are Agile and assume we don’t have to document what we do (no matter what SOX, HIPPA, FTC, ISO or anyone else has to say).

To summarize, we have poor communication between business reps and development regarding needs, poor quality due to overworked and under-appreciated QA, and compliance\legal\information assurance breathing down our necks because they need something, anything, showing we actually are thinking through how we handle data.

For some, this little picture we painted here might represent exactly where you live now! For others it may paint a picture of where you see yourself headed.

I give you the Agile BA.

Let’s start with the developers. They need someone who can talk business-eez and translate that into technical jargon. They can’t get the PO to spend any dedicated techie time with them but the need is still there on a somewhat daily basis. Now, don’t mistake this to say the BA should play the PO role. One  voice makes the call on value and priority in the backlog. But an Agile BA will have a great relationship with the product owner and help create a bridge between the two by becoming a business to IT translator.

The most common area of success I see in this “translator’ role is when teams practice the “Three Amigo’s” approach to development. This is where a developer, tester and BA will sit down and hammer through the known details of each story before any actual work is done.

Ever needed something from someone who spoke another language? Remember that feeling of utter relief you felt when the Good Samaritan who could translate stepped in to assist? They didn’t tell you where to go, but they could sure help in getting there.

I give you the Agile BA.

How about our testers; our QA brethren? They are the ones who get code at hour 11. They are the ones who are pushed to sacrifice quality for time. How can our Agile BA assist?

Being as familiar as they are with the backlog of work, requirements, and business/technical needs, they are ideally suited to assist in some of the higher level testing efforts that will help ensure new levels of quality. They are careful not to encroach into the technicalities surrounding the QA world, but make themselves available to QA as an additional resource to ensure completed requirements before passing on to their PO for final approval. They are many times best placed as a final set of eyes to keep the team from the burden of unwanted rework. In this scenario I have seen the BA become the product owner’s right hand (wo)man.

QA can feel a little on an island at times. They are the bearer of bad news and the messenger is often killed in these circumstances. They need someone to help evangelize quality and point out what we will simply call ‘opportunities for improved code design’.

I give you the Agile BA.

Finally, agile documentation (not an oxymoron).

There are companies out there, who I won’t address by name, which have refused to adopt Agile approaches due to the perception that their compliance level will be at risk (no pun intended) due to the perceived lack of sound documentation in Agile practices.

It’s important to remember that great Agile teams will do what is needed to provide the business with top value. If the business has determined that a certain level of documentation is required in order to continue to provide this kind of value, than the Agile team had darn well better plan for that documentation need.

Working software is, according to the Agile Manifesto, of considerable value to the business. But remember that the manifesto does not say documentation is without value. It simply states working software is considered of more value.

Well...yeah... of course. We want the software, predominantly. But real world tells us that we need to prove compliance and best practice data security. It’s hard to do that with a poorly written user story!

I give you the Agile BA.

With their day to day involvement on the Agile team, inclusive of the product owner, they are ideally placed to help define which parts and pieces will create the most value from a documentation standpoint. They can work with the team facilitator/scrum master/etc. to find out who needs what and then help translate that into streamlined and useful (valuable) documentation.

Funny thing is the teams I’ve worked with find the Agile BA to be one of the most critical roles on the team! We can swap out a developer if need be. Rotate the testing around a little if you must. But please, PLEASE don’t take away our business analyst!

There is a side effect though. Our Agile BA’s are often asked eventually to become product owners themselves. Why?

Well let’s walk through this again...
1) They have experience in translating business needs to developers
2) They know what to look for in quality products
3) They have experience working with business partners in backlog prioritization
4) They can determine streamlined documentation needs that fit business value
5) They know what it means to be engaged with an Agile team day after day.

I’ll be honest here...that’s a product owner worth their weight in gold.

Agile is all about providing value. When you look at the many ways an Agile BA provides value to their team, how could anyone question whether or not there is a seat available at the table? The Swiss Army Knife is considered a must have by some (Swiss Army anyone?). It’s flexible, useful, valuable...dare I say...Agile?

Make no mistake, as timeless as that tool is, the time is coming very soon when you won’t see an Agile team without their handy-dandy Agile BA which you will have to pry from their cold dead hands!

The Art of People: Facilitation, Leadership and Team Dynamics

 illustration from www.justontarte.com

In one word, describe for me an exceptional leader.

Perhaps words that come to mind could be courageous, humble, accountable, selfless or perhaps even moral and ambitious.

Are any of these wrong? Of course not. We would like our leaders to display all of these qualities and probably more... ideally.

Now, in one word describe a great facilitator.

Perhaps words that come to mind include observant, listener, and neutral, persuasive as well as courageous and humble. You might also include proactive in that list.

In today’s world of teams and team dynamics, which require cross-cultural, cross generational and gender neutral atmospheres, requiring these teams to work together in a way they have never before experienced can create an often contentious and uncomfortable atmosphere which could have a huge impact on both team and corporate culture!

The need for skilled leadership on these teams has become obvious. What has not been obvious is where we find the folks with the right mindset, disposition and all of those qualities we listed above in order to give our teams and organizations the chance they need to be successful.

One thing is certain; it’s not for lack of volunteers.

Plenty have stepped forward to say, “I want to be a leader.” In an Agile world, some have gone so far as to embrace the mindset that Scrum Master = Team Lead = Management. In other words, “My team will do what I say if they think I’m the one in charge.” This mindset reflects someone who is focused on the role they have, not the goal we are all trying to achieve; this goal not the role focus is one I’ve heard championed by Ellen Gottesdiener of EGB Consulting on many occasions.

In other cases, we may be simply slapping the first hand in the air with a team of their own and a two day certification. We then ask them to expertly display all of those qualities we are looking for atop this article. And by the way, no one reports to you on that team. You simply have to get all of these folks to perform at a high level in a methodology they have never used before and communicate in a way they’re not used to. Easy...

Did I mention this will also reflect in your annual performance review?

I recently ran a workshop for one of the larger national IT recruiters for a group of their clients on the topic “This Doesn’t Feel Agile”. The concept is one of coming together to discuss common issues seen in Agile adoption and walking away with practical ideas for helping to ease that adoption and realize the benefits. I introduce the group to a commonly seen set of problems such as culture, executive acceptance, team acceptance, training, resources, etc. What’s interesting is that culture and training often get to the front of the list quickly.

In discussing these two topics, the ones leading the teams are held in highest accountability. They are evangelists within the company for Agile practices, they are trainers themselves, they help mold the culture and assist in identifying areas of need for the teams and individuals.

So this begs the question, why do we not take more time to ensure we have the right people with the right skills in this role as opposed to assigning it just to say we have that person there?

What could be the result of having the wrong person in that role?

First off, it should never, EVER be a staff manager!

Why? Aren’t they leaders anyway? Not necessarily. It’s true they are people managers, but they may not be true leaders. Additionally, can anyone argue with how placing a staff manager within a team as a Scrum Master or Team Facilitator would skew the overall team dynamics at just about every level?

Let’s say you have someone volunteering for the role. What could the ramifications be of having the wrong person?

·         Poor team dynamics, infighting

·         Lack of productivity

·         Culture of finger pointing and ‘Teflon accountability’

·         Lack of trust

·         Zero communication

But, what if you find the diamond in the rough? What if you get that person that just...well...gets it?

Consider yourself a lottery winner! Some of the outstanding traits we would like to see in our leaders can be taught. Conversely, I have encountered some of the most honestly motivated command and control personalities, who wanted desperately to learn better servant leadership qualities, simply fall back to habits that were too engrained in their day to day personality to truly help their teams. Some to the point where the teams were literally begging to have the person replaced due to their sheer ‘bull in a china shop’ nature.

Good for them for recognizing the need for change but unfortunately some people just aren’t wired that way.

In an Agile Team Facilitation and Team Leadership workshop I held recently, I had a young ‘millennial’ college student attending as an active participant and listener. Not long afterwards she sent me this visual representation of her experience: 

Michelle here outlines 9 aspects of great leadership and facilitation she took away and aspires to apply.

Her long term aspirations include event planning and project management. I’d say she’s on the right course. She’s also seeking to enhance the skillsets she recognizes early on that will make her better long term for her teams, organizational culture and one day her own personal clientele.

A diamond in the rough?

There are a few companies out there who take great pride in grooming their leadership and placing the right people in the right places with the tools they need to be successful. How do you know if it’s working? You can see their culture in everything they do. You can probably list a handful of them off the top of your head.

What is your organizational culture? Do you have a leadership strategy? Are your leader’s facilitators or do they simply manage people?

The long term outcome could be the difference between organizational success and failure.

Who's On First

 

robert woods - April 8, 2014

One of the most famous conversations ever to take place went a little something like this:

Costello: Well then who's on first?

Abbott: Yes.

Costello: I mean the fellow's name.

Abbott: Who.

Costello: The guy on first.

Abbott: Who.

Costello: The first baseman.

Abbott: Who.

Costello: The guy playing...

Abbott: Who is on first!

Costello: I'm asking YOU who's on first.

Abbott: That's the man's name.

Costello: That's who's name?

Abbott: Yes.

Costello: Well go ahead and tell me.

Abbott: That's it.

Costello: That's who?

Abbott: Yes.

Was it clever simply because it was funny?

No, it was funny because people have actually found themselves in a conversation exactly like this one at one point or another and understood the absolute frustration!

Abbott made the assumption that what he was saying made absolutely perfect sense. If you watch the video here, you can see the growing frustration by Abbott attempting to comprehend why in the world Mr. Costello doesn’t get this plainly worded explanation.

In my work as a Scrum Master, Team Facilitator and Project Manager I have sat in on more of these exact conversations than I care to remember. I have looked on as our technical guru’s attempt, in what they consider plain English, to explain the reasons for the back end table and code adjustments they need to make while the product owner looks on as if they were listening to someone attempt to describe the theory of relativity in mandarin Chinese. You know, that eyes squinted, mouth half open look of “heh?”

The results?

Everyone walks away with a false sense of productivity and then complains when what was expected was not delivered. Developers insist acceptance criteria were unclear and business ownership insists IT only builds what IT wants to build. So... ‘Who’s on first’ here?

Breaking the Language Barrier

Part of the success in man’s ability to break the sound barrier was recognizing there was one to begin with.

First we need to have everyone in the room recognize that we have different jobs for a reason. That being said, this is no different than having a room full of folks who all simply speak a different language. Imagine that exact scenario, would we walk into a planning meeting assuming everything we were about to say would be even remotely understood by the folks attending?

Of course not!

We would immediately start looking patiently for opportunities to help them gain a better understanding of what we needed to get across. We would in turn, hope they would have the same patience with us as we attempted to understand what it was they needed us to comprehend.

Understand from the outset that there are simply different languages spoken here; different mindsets. Both sides need to have the patience to take the time and explain, to the best of their ability, using simplest means possible, in order to get across their point and then look for absolute signs of confirmation of understanding on the other end. Verifying multiple times if needed.

But I’m Not A Good Self-Explan..a..tioner..

In some cases we may simply have enough self-awareness to understand we sometimes don’t explain ourselves well.

Congrats!

It takes humility to come to that conclusion. Conversely, get some help explaining! This is where some of the Scrum Master, Project Manager and Team Facilitators come into play. This is also why you can’t simply slap that label on anyone with the spare time.

More than once I have found myself in the position of playing translator between someone speaking “IT mandarin” and “business Swahili”. It’s not an easy job and not for the thin skinned. Often, you aren’t merely translating; you are facilitating two sides of a heated debate. Part of the debate having to do with lack of understanding and the other part having to do with actual difference of opinion.

A highly skilled facilitator will assist both sides in three ways:

1)      Both individuals should walk away with a much better understanding of the language spoken by the other person.

2)      A decision based on mutual agreement should be formed because of that improved understanding.

3)      Future discussion should flow much easier now that we have found a common ground to work on.

Slapping someone with a Scrum Master certification (not that there’s anything wrong with having a CSM) does not make them qualified to get those kinds of results. It may only add a different language into the confusion. Whomever takes on this dubious task must understand that this is an extremely important role played for both the team they help and the business they are working for. Appreciation will often be sparing but results will be outstanding when done well!

This person should take the time to know their teams as individuals and as a whole. This will better equip them for the difficult discussions that will inevitably take place and get results faster.

So....who’s on first?

I’m going to procure for myself a brand new tee-shirt that simply says, “Have the conversation.”

If the question involves lack of communication, lack of understanding, lack of information or lack of planning. The answer is, have the conversation.

If retrospective sounds like a broken record of “we didn’t have enough acceptance criteria” or “it didn’t get accepted because we were missing something.” The answer is, have the conversation.

Every time I hear one of the above sentiments I am fully prepared to rip open my button up ‘business casual appropriate’ dress shirt and, in a very Superman-esque way, display my tee with pride.

Does anyone involved NOT want to be successful? No, or course not. We all want the same things; a) to enjoy who we work with, b) who we work for and c) what we work on. Then why are we so averse to taking the time to regularly collaborate on what we consider success?

And I don’t mean just a one-time meeting to create a pseudo checklist (which will probably change before we walk out of the meeting room). What I’m talking about is real, meaningful conversations on a regular basis to ensure we are doing the right thing at the right time.  

It’s not micro-management...its micro-collaboration; the distinct difference being respect, trust, understanding and outcome.

Who’s on first. It’s a statement not a question.

See...that wasn’t so hard now was it?

The Power of Belief



What are you capable of?

robert woods 3-26-14

The power of belief is one of the keys to reality creation. To be able to consciously create your ideal reality, you must believe that you already have that which you want in the present moment. - The Power of Belief - Take What You Want for Granted By Tania Kotsos

It’s not that simple. You’re asking the impossible. It can’t be done.

I once worked with a CIO for a mid-sized healthcare firm who leaned over during a meeting and whispered the words, “This is the most fearful company I’ve ever worked for.”

Now, granted, this is a company that deals in PHI (protected health information) and the fines\jail time for allowing this data to become public is quite hefty. As much as anyone he understood the ramifications around a cowboy driven environment of data handling. But that’s not what he was referring to.

Instead, he was referring to the absolute fear of failure and lack of innovation surrounding the culture of the company. He recognized that such a mindset paralyzed his employees and helped fan the flame in the corporate financial burn out that was taking place in front of him. But the culture had been set long before his tenure. The difficulty lay in championing change.

There is an evolution taking place within, not just software development circles but many flavors of business, that corporations are having a hard time adopting. The mantra of that change is, “don’t be afraid to fail because failure helps breed innovation.” The idea itself is a relief to many ears who have for years been asking for the opportunity to get their ideas in the open and be given a chance to just “try it out and see if it works” without the fear of job security. But, for equally as many years they have been hit over the head with the cult of corporate personality hammer evangelizing risk management and dire repercussions of failed ideas. It defined the culture of an entire generational workforce.

The other difficulty in the corporate adoption of this concept is simple personality. Whether due to background, upbringing, or simple genetics; there are those out there who would rather be told what to do as opposed to have to innovate to find the solution. Perhaps this is also an accountability issue.

“If I do what YOU tell me to do, and it fails, I can blame YOU. If it succeeds, it was a joint effort.”

How do we change this behavior? How do we adjust an entire corporate culture?

The quote at the top of this article highlights what is called ‘the power of belief’; the concept of placing such strong faith in the success of an outcome or idea that it’s practically successful before even followed through. Some others might simply call this self-confidence. Some people inherently display this quality, for good or for bad. It can be seen as both endearing and as arrogance depending on your perception of the person as a whole. But it’s hard to escape the fact that these people often find themselves successful. Is it because they are smarter? No. Because they are given more opportunities? Not always, but in some cases they will be given more because of the aura of success they display.

From the individual standpoint, this power of belief will often cause them to work much harder towards the successful outcome of their idea. They are so convinced it will work, they nearly exhaust themselves proving it. Whereas the less convinced person, without this belief, will be willing to give up on their idea much faster, doing so with a heavy “I didn’t think this would work” sigh.

Within a corporate culture, this change in attitude can come from many levels but the most successful adoptions have come from the absolute leadership. Make no mistake, corporate culture is primarily driven from the top down. If you’ve ever read ESPN.com’s Tuesday Morning Quarterback by Greg Easterbrook, you will have heard him often refer to football coaches who are not playing to win; they are playing not to lose. There’s a difference. The ones playing to win are the ones willing to take calculated risks and willing to allow failure if it doesn’t work out. They are also wililng to take whatever heat comes from the failure. The ones playing not to lose simply stick to the status quo so, if/when they lose, no one can say they deviated from the norm.

Executive leadership has the same effect. There are those playing to win and those playing not to lose. Easterbrook notes that the winning percentage of coaches playing to win is considerably greater than that of those playing not to lose. Additionally, they are considered innovators and geniuses; respected by their teams for being willing to take a chance.

Culture starts from the top. If we give our employees the perception that jobs will be had for failed innovation, you won’t get ANY innovation. It’s that simple.

But, as leadership, if we evangelize and follow through on the culture that innovation (especially failed) will be recognized and rewarded, we are changing the mindset of the individual from one of fear to one of opportunity. We are starting to plant the power of belief seed. But you can't just say "don't be afraid to fail". You have to act on it and set the example.

As an individual, once that culture has been marketed, it’s now time to take advantage. Plenty of people sit around talking about their great ideas; few follow through. Thomas Edison once said, “Many of life's failures are people who did not realize how close they were to success when they gave up.”

But you have to start somewhere.

We spoke above about those who feel so strongly about their ideas that they refuse to give up on its success. Isn’t that what Edison was saying in a nutshell? You can’t force someone to believe in themselves or their ideas. That power of belief is like a rose garden; if you try and force it, you’ll never get it. But, if you give it the right environment for success, feed it and nurture it, the results will astound you.

The point is this...that CIO eventually left the company. He was a single voice for a changed culture singing in a room full of fearful risk-adverse opera singers and it pained him to see the results. But he was on the right track.

I have also had the pleasure to work for another CIO who lives, breathes and eats this power of belief mindset. He encourages trying new things and rewards people for putting their neck out there, regardless of outcome. All he asks is that we learn from any perceived failure and consider it an opportunity for improvement. Has this changed the individual mindset of everyone under his watch? Of course not. Sometimes it’s simply genetics. But the environment for success is there. The rose garden is in place. Perhaps through nurturing, we can help these folks to blossom.

He will hear it’s not that simple, you’re asking the impossible or it can’t be done.

Perhaps

But we’ll learn, adapt and try again. Just believe...

Standup and Listen!

Robert Woods
Agile Coach & Trainer
Aarons, Inc.

Standup & Listen!

Tell me...can a morning standup that consists of up to 30 people, all working on a corporate point of sale system spanning over 2100 stores and affecting every department in the company...be effective?

The Agile coach in me says, "No way is anyone getting anything out of that standup. Most don't even want to be there to begin with!"

But at Aaron's, innovation with 'agility' is at play. After spending years in textbook Scrum, Scrum-Ban and Kanban world's, we're taking a little time to play around with process and see what sticks. Oh sure, the pre-packaged processes worked just OK for a little while, but Agile is about innovation right? That constant improvement thing?

In an effort to shake things up a bit, create a proactive framework around the upcoming backlog of work requests and work to improve on value delivery, a particular Aarons software director approached me with the idea of taking  4-5 teams of 8-14 people each; silo'd at times by contractors/consultants/internal employees, and instead creating pods of smaller, more focused teams reflecting a blend of all of these roles. Additionally, we would move away from the Scrum based dedicated planning sessions, estimation exercises and burn down charts. This will have more of a constant flow\Kanban feel to it. The goal? Increased business engagement, improved team collaboration and dynamics, exposure in more areas to business needs and delivering more value quicker.

My response? "We're innovating the process....why not!?"

Too many organizations allow the process to dictate the people. "We were told to have planning sessions so we're going to sit in planning sessions for as long as it takes! We were told to estimate so we shall live and die by our estimates and burn down charts. If they aren't accurate...we shall wear sackcloth and gnash our teeth at each other in disappointment!"

Not here....not this time.

This time we will let the body of work and needs of the teams determine the process and then we will be humble enough to continue to make changes as the teams see fit to do so. Business owners and product champions will hold themselves to a higher standard of knowledge and availability to make up for lack of dedicated planning. Every story will be expected to have continued conversation as opposed to one conversation where everyone walks away assuming we know everything about what we are getting into. WIP limits will help ensure reduction in bottlenecks of work and have been made horizontal as opposed to vertical. In other words, the entire TEAM is responsible for doneness at EVERY level as opposed to WIP in their own little world. Oh...and by the way...we dont care if you are a contractor, consultant or internal employee; we all want to be successful and we all make up the team!

The result? Well, we retrospect on this change in true Agile nature. Teams were polled on how they like the change. Debates and discussions ensued. On average, the response was overwhelmingly positive. Teams felt more was getting done. Collaboration was at an all time high. Dependencies were identified much quicker and feedback turned around much faster. There is a buzz of discussion and activity. Was it worth making such a radical change? Time will tell.

Every morning we have a standup for each team to be able to provide updates and gather information as needed. Not  everyone is expected to attend save for one rep from each team (about 6-7 people in all). Typically, standups were once considered monotonous. Now, as a general rule, everyone shows up. The benefit of the knowledge sharing that goes on has been infectious. Make no mistake about it...this is a culture shift.

We will preach about Agility and embracing changes in requirements, 'even late in development'; sometimes even looking back on our accomplishments as badges of "agility" honor. But, then, we will rigidly stick to our processes that taught us to embrace change and innovation to the sacrifice of self and team improvement.

Remember, Agile is as much about constant self improvement as it is about delivering value; and the two are not exclusive of each other. Don't let the process define you. Define the process and embrace the new you...again.