Skip to main content

Tag: Team

Build Trust; High Five Your Teammate

Written by Kupe Kupersmith on . Posted in Articles. 2 Comments on Build Trust; High Five Your Teammate

BuildTrust1When I began writing this blog series at BA Times last year, I aimed to focus on the behavioral characteristics of our role as business analysts.  My goal was to go deeper than the science of our role and focus on the softer skills. I wanted to give you my thoughts and concrete ways to separate yourself from the pack of BAs by giving you ideas to up your game as a BA. After 10 months and 20 blog posts I have discovered the one thing, above all else, that is the pillar to your success as a business analyst That one thing is trust. The higher the trust relationships you have, the more success you can achieve.

When It Hit Me

Last week I delivered a webinar, The BA Life Beyond, Charts, Diagrams, & Documents. The purpose of my webinar was to help the attendees understand the importance of the “soft” skills and behaviors needed to be an excellent, desired BA. As I was working on the content with a colleague we both read Stephen M. R. Covey’s book Speed of Trust.  Quickly, trust stood out as the pillar that supports the underlying competencies outlined in the IIBA BABOK® Guide V2.0, the “soft” skills. If you have trusting relationships, communication is more efficient and easier, your ability to lead and influence increases, your teamwork improves dramatically, and the list goes on.

Why Trust?

In his book Covey asks a few simple questions that help you understand why trust is so important.  Take a minute to think about these as I lay them out here. For the purposes of this blog think of a work relationship, although this can be applied to any relationship.

Think about a person with whom you have a high trust relationship. Describe this relationship?  What’s it like? How does it feel? How is the communication? How well do you communicate?  How quickly can you get things done? How much do you enjoy this relationship?

Now think of a person with whom you have a low trust relationship.  Describe this relationship?  What’s it like? How does it feel? How is the communication? Does it flow freely…or do you feel like you’re constantly walking on land mines and being misunderstood? Do you work together to get things done quickly or does it take a disproportionate amount of time and energy to finally reach an agreement and execution? Do you enjoy this relationship or do you find it tedious, cumbersome, and draining?

You can see that in high trust relationships you move faster, communication is clearer, and a team with high trust will be able to solve problems and make decisions more efficiently.

Build Trusting Relationships

Covey provides 13 behaviors of high trust people and leaders worldwide.  One I want to talk about today is “Show Loyalty”.  He talks about showing loyalty in terms of giving credit freely.  Acknowledging the accomplishments of others, shows you the value that person brings.  People want to be on your team if you give credit where credit is due and not take the credit for the work of others. 

Here is where the high five comes in.  In the March 15, 2010 Sports Illustrated there is a fabulous article written by Chris Ballard about the high five and all of its variations.  He shared findings from a study that examined the effect of “touch” (high fives, head slaps, shoulder bumps, etc.) in the NBA.  What they found was that the more high fives, head slaps and shoulder bumps, the more wins the team had.  The opposite was also true.  The teams with the least amount won the least amount of games.  And the individuals that high fived the most were the team leaders. 

What is a better way to give credit to someone than a high five?  When a teammate facilitates a great elicitation session, feel free to walk up to them and deliver a high five as you are leaving the conference room.  As you are working on designing a solution and a teammate has a great idea, reach across the table and offer up a fist bump. 

I know some of you are thinking I am crazy.  Maybe you’re right.  People may be a little thrown off if you jump in the air in hopes to connect with a flying shoulder bump or put out your forearm going for a forearm bash.  But, you get my point! Right?  When others do a good job make sure you acknowledge it. 

High fives for everyone,

Kupe

“Show Me the Money” – Value-Driven Requirements!

Written by Robert Galen on . Posted in Articles.

For those of you who follow my posts you know that I’m incredibly passionate about the Agile Methods. I’m not some youngster who is blindly following the newest game in town. No, I have many scars related to other methods and approaches. However, I’ve discovered that they’re the best way to do software development and come away with a life.

I’ve been exposing some of the core practices or thinking models of agility here. Another that I’d like to share is the importance placed on business value when it comes to the Product Backlog (requirement lists).

Now trust me, I realize how hard it is to quantify true ROI on a per requirement basis. I think it’s virtually impossible to do that and it’s not what I’m implying. Instead though, what if we could get a group of key stakeholders together and have them analyze requirements or themes of requirements and assign some sort of relative business value? You could then use this valuation (priority in some sense) to guide your further refinement of the requirements, or to decide on UX efforts required, or to decide on where to invest more heavily in design and construction rigor. This sort of value-driven analysis might prove incredibly useful in guiding your work.

To be honest, the agile methods have surfaced just such a technique that I want to share. It’s called Planning Poker and here’s how it goes—

ShowMeTheMoney

Planning Poker

Mike Cohn originated the popular method that the agile methods use to estimate the size of user stories. (I’ve explained those in previous posts). Planning poker is a collaborative technique where team members get a series of cards marked with values that represent relative level of effort. A modified Fibonnaci series is normally used for the card values: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, and infinity.

As each user story is examined and discussed, there comes a point where you want to “size it”. Each team member thinks about the size and then “votes” by selecting and throwing one of the cards down to represent the relative size.

Once thrown, the team discusses the high and low values and explores the why behind everyone’s selection. It’s a wonderful way to drive relevant discussion. The team continues to re-vote until they feel they have sufficiently narrowed the values into a uniform selection for level of effort. Then they move onto the next card and so on. So this works for estimates…

Value Poker

What if you use the base technique, but change up the cards? A very interesting and healthy extension to Planning Poker is Value Poker. While the basic technique remains the same, the setup is different. In this case, you place monetary values on each card, say: $500, $1,000, $5,000, $10,000, $20,000, $25,000, $50,000, $75,000, and $100,000. The list is really determined by your product and business domain and mapping relatively realistic cost/ROI amounts to the cards.

Once this is done, you view each user story (requirement) and try to apply a value to it. Again, team members throw their cards simultaneously and discuss the differences in value perspective. By recasting and further discussion, each story is assigned a value that relative to other stories and relative to the overall value that the product or project will deliver to the business.

In agile shops, this helps initially with prioritizing the work on the Product Backlog, in that business value drives prioritization and delivery flow.

However, I also find that these value discussions creep into all aspects of the project. From a BA perspective, it can help determine the true “Top 20%” of requirements that need your utmost care and attention. You might review these first, or use different tools and techniques to refine them, relative to the other requirements. You might review them with different sets of stakeholders, etc.

The point being, that valuation matters not only in the ordering of the work, but in all aspects of the project. For example, imagine you’re a tester and the top 10 of 100 requirements have a cumulative value of 67% of the overall project. Would that change how and what you tested? I suspect yes!

Value Poker Twists

There are several twists you can make to the technique.

One is to maintain different values based on the functional role of the team member. So you might have red cards for QA participants, blue cards for development participants, green cards for business facing participants, and yellow cards for BA participants.

This differentiation allows the entire team to quickly view distinctions in level of effort, or value in this case, from a constituency point of view. If, for example, the business values a user story at a very high level, but development does not, then some functional alignment discussion should occur.

Another twist is to give each valuation team member a fixed pool of funds to spend. This is my favorite approach, in that it encourages each member (project stakeholder) to not only consider relative value, but to spend their funds well (wisely) across the user story mix for the project.

It’s common to come out of sessions where the business has valued a small set of user stories quite highly. This information has then led to increased care, diligence, and quality on the part of the team when they get to defining and implementing that set of stories.

There something different about saying-

This is our #1 or highest priority feature and…..

versus

This is our #1 feature AND it provides 42% of our overall project valuation / ROI

Don’t you think?

Wrapping Up

I hope this discussion on value has perhaps opened you to another perspective when ordering and prioritizing your requirements…and work. Another positive side-effect of the technique is that it starts to skew our perspective more towards the business side. I think that’s a very healthy point of view.

So, poker anyone?

References:

Don’t forget to leave your comments below

Be a Leader; Focus on Change

Written by Kupe Kupersmith on . Posted in Articles.

bealeaderLast week I had lunch with a former co-worker to discuss an improvement plan she was implementing for a team of business analysts.  I told her I would not reveal her name in this blog so let’s call her Wonder BA. Wonder BA is an active reader of this blog, so maybe she’ll chime in with a comment or two on this post and reveal herself. Wonder BA was recently promoted and given the responsibility to lead a BA improvement initiative. As we discussed her approach and things to consider with this initiative, I noticed the conversation did not focus on business analysis. There was little talk about an analysis process, how the BA role was used in their agile environment, or how to organize the BA group. The main focus was on the project team environment, how the team perceived the value of the BA, what their management team wanted to see more of from the BA community, and steps to roll out the BA improvements. It was all about ways to ensure this initiative or more specifically this change initiative would be accepted and adopted in Wonder BA’s organization. We talked about how to assess the change readiness of the organization and the individuals impacted; her thoughts on if the culture in her group was one that will accept and adopt the changes she wanted to implement, and how to motivate the individual BAs to embrace the change.

This got me thinking about the change created with every project we work on.  Too often the project team’s focus is on the features or the new process being implemented as a result of the project. Time is spent worrying about time.  Sleep is lost thinking about ensuring we have the right resources to create the solution.  Once the project rolls to production, the team is happy and moves on to the next round of enhancements.  Teams need to start spending more energy on how to help the users and organization accept and adopt the change created by the project.  Often the business comes to the project team asking for new enhancements or a new application to help them overcome the challenges they face.  But too often, the impact on the business of introducing a new process or application is underestimated. 

As I was writing this blog I called a trusted thought leader in change management, Darshana Patel, change and conflict specialist and founder of SplashMaker LLC.  I asked her opinion on this topic and how BAs can help with adoption. Here is her response:

“With increasing efforts to improve the reliability of project outcomes, a new realization is emerging: a successful project does not equal a successful change.  Project and change are two sides of the same coin.  A project delivered on time, on budget, with targeted scope and quality does not guarantee adoption, institutionalization, and sustainability of the solution.   

With the business analyst positioned closest to the pulse of the people and processes affected by a project, here are five key considerations for the BA in planning for and executing successful change.

  1. How will individuals, groups, and the organization be affected by this project? How do we motivate each level to align with the changes required by the project?
  2. Which levers do we need to adjust: goals, culture, structure, and process to support ongoing adoption? Who needs to be involved to make this happen?
  3. What is the organizational context of this project? What dynamics are at play that may impact the likelihood of success?
  4. Politically speaking, who supports or needs to support this project? Whose lack of support can sink the short or long term viability for success? What information can be provided to influence their position?
  5. Who can we employ as change agents to actively broaden and strengthen the coalition of support? What is the formal and information communication plan to propagate the themes, messages, and ideas that align conversations and people with the project?”

Early in the project, begin to think about the points Darshana raises. You still need to focus on the features and new processes to be implemented. But does any of that matter if the new features and processes are not adopted?  As a BA you are a leader.  By focusing your attention on planning and executing change you will be acting like one.

To change!

Kupe

Don’t forget to leave your comments below

I See What You Mean… Leveraging Transparency!

Written by Robert Galen on . Posted in Articles. 1 Comment on I See What You Mean… Leveraging Transparency!

One of the core tenets of the agile methods is transparency. I’ve been doing agile for nearly 10 years and this is one of the tenets that I find myself understanding and appreciating more and more as I gain experience. It’s the tenet that keeps on giving.

Let’s generally define it first. What is transparency?

I think it comes down to exposing the inner workings of a software project for all to see. To have high comfort and honesty in sharing project “state” with team members, stakeholders, and company leadership. Included is the ability to engage in honest, open dialogue surrounding any issues leading towards requisite project adjustments.

How Do You Foster Transparency?

The first part of it is simply sharing “state”. For example, I view early reviews of requirements documentation as being a transparent moment-particularly if they’re incomplete. In Scrum, each iteration ends with a Sprint Review where the team demonstrates the code and artifacts they’ve created during the sprint (iteration). There’s no simulation here. Instead the emphasis is always on working code and relevant models completed in the sprint.

So, stakeholders can see and react to exactly what we’ve done so far.

Another Scrum practice is the daily standup meeting or daily scrum. Here the team gets together and shares the progress and challenges they’re facing in the current sprint. If they’re behind, it’s evident and corrective action discussion occurs in real-time. If they’re ahead, then discussion surrounds pulling more work into the sprint. Either way, you understand the ebb and flow of the work on a daily basis. Scrum teams welcome visitors to the daily scrum as a means of transparent status gathering.

A final Scrum practice that fosters transparency is the notion of a Burndown Chart. You can see an example below. In this case we’re burning down cumulative work that the team planned over the course of a sprint or iteration. The green line is the perfect trending line. Each day, the team gets credit for completed task work and “burns down” the chart hours appropriately. You see in the example that the blue line gives an entirely different view of the team’s progress than does the red. It opens the door for questions from the team and stakeholders – leading towards comfort or adjustments.

iseewhat1

What Does Transparency Do?

It removes wishful thinking on the part of the team and stakeholders. Instead of thinking that the project is about 40% complete, a transparent view is that 32 of our 96 features are absolutely complete, with 12 being works in progress. That implies that we are exactly 33% complete. And at this rate, it will take us twice the current progress interval to get the work completed if the features are roughly the same in size and complexity.

It keeps us grounded in the now – not worrying too much about the future. Instead, how are we trending towards our next deliverable? And, if not so well, how do we take corrective action now to improve our potential for delivery?

It creates conversations surrounding reality and movement towards your goals. I literally love it when a stakeholder stops me in the hall and ask about our current burndown chart for a specific Scrum team…

“Bob, I’ve noticed that It’s day 4 of a 10 day sprint and the burndown chart seems to be flat. That implies that we’re not making our expected progress. Yes, it does, I say. Well what can we do about it? I offer a couple of thoughts. First, we don’t know if we have an issue yet. The team may simply be working on things that haven’t been integrated yet, and we’re “on track”. So we ought to engage the team and ask them how things stand – perhaps in tomorrows stand-up?”

If we are tracking worse than expected, then I’ll engage the stakeholder right then with trade-off options. I’ll direct them away from quality trade-offs and focus on scope. I’ll usually ask questions surrounding jettisoning scope while still being able to meet our sprint goals. All the while, trying to make the problem and the solution ours instead of mine.

So What Does this Mean for the BA?

Leverage transparency to your advantage. Open up your work incrementally, early and often, for review and feedback. Don’t get defensive when you hear things that you don’t quite agree with. Take the feedback, internalize it, and take appropriate action within your work’s flow.

Let everyone know how you’re progressing towards project goals. What are your high priority focus points and conversely, the low priority counterpoints. Let everyone know how your work aligns with the schedule. Don’t hide anything and don’t be optimistic or pessimistic. Just relay where you honestly stand and the potential for adjustments.

I encourage everyone to simply try transparency. It’s the gift that keeps on giving!

Don’t forget to leave your comments below

Agile’s “People over Process”… What’s the Point?

Written by Robert Galen on . Posted in Articles.

There are several bloggers on BA Times who have written about agile methods. They’ve compared them against more traditional methodologies and missed many of the central themes and mindsets within the methods. In particular, one of the often missed points relates to documentation…imagine that! Let me provide some additional context here.

From my perspective, traditional methodologies (Waterfall, Ad-hoc, RUP, etc.) try to capture the essence of a project in the documentation for the project. The thinking goes:

  • We’ll gather our best people together
  • We’ll put them in a room and they’ll think deeply
  • They’ll architect and develop models
  • They’ll analyze and write requirements
  • They’ll design the system
  • They’ll pull together a detailed, end-to-end plan
  • They’ll plan for quality and risk and process
  • They’ll hand it off to someone else to execute…

All of the intellectual property – the experience, the skill, the decision-making, the nuance, virtually all of the creativity has been stuffed into the documents. Usually there’s a view that now that all the hard work is done, all we have to do is find a team to simply execute the details. In fact, almost any team could deliver this “well crafted” project…couldn’t they?

Then Voila! Our Work Here is Done!

The agile methods come at this situation from a different direction. Why? Because the above approach usually doesn’t work. I contend it’s why we’re still failing in nearly 60% of our software projects to meet stakeholder expectations across one or more dimensions of our projects. (Chaos report data) We’ve forgotten an important point in the above strategy. It’s not that the documentation is bad. In fact, we often need much of that work done. No, the thing we’ve missed is the people, the knowledge worker, the team. In other words us!

We’ve forgotten that plans don’t execute projects – people do. Architectural models don’t guarantee a sound architecture that scales well under adverse, real-world conditions – people do. We’ve forgotten that exhaustive requirements don’t guarantee that we delight our customers and exceed their expectations – people do. We’ve forgotten that quality doesn’t get tested in. Instead it gets built in – by the people. Let me characterize it in another way; here is the agile people mantra:

  1. It’s ALL about the People collaborating around real working code!
  2. It’s about writing some more code to verify our presumptions in writing about the code…
  3. It’s ALL about the People collaborating around the new, real working code!

You see you can’t solve problems by trying to predict the future solely within documentation. Here’s an agile-esque and potentially different/better approach to attacking a project:

  • You find a wonderful, highly skilled team.
  • They do “just enough” documentation to get started
  • They include the customer in all decision-making; in fact, they’re part of the team
  • They start building pieces of the systems, gaining feedback
  • They’re transparent to the customer, management, and stakeholders about their discoveries along the way
  • They make informed adjustments as a team and with the business where necessary
  • They triangulate the project through all of the uncertainty and deliver the most meaningful set of features to the client when they need it

In agile, it’s not about the pre-work or the documents. It’s about the people. Included with the people is the customer. They work together, are inspired and motivated together and they deliver together. It’s about self-direction and honest teamwork. It’s about discussions and openness regarding project state, progress, and trade-offs.

I would characterize any project that elevates and engages their teams in a holistic manner as being agile. Likewise, any project that allows their teams to think and respond with common sense to each project’s unique requirements and challenges as being agile. In the same way, projects that allow them to decide what needs to be documented and, heaven forbid, what doesn’t…because it adds no value, as being agile. In other words, any project that truly trusts and engages its people, can be defined as being agile!

If this describes your project environment, then independent of your software development methodology…you are, gulp, Agile!

Don’t forget to leave your comments below

Robert ‘Bob’ Galen is the President and Principal Consultant of RGCG, L.L.C. Bob has held director, manager and contributor level positions in both software development and quality assurance organizations. He has over 25 years of experience working across a wide variety of software technology and product domains. Bob can be reached at [email protected]