Skip to main content

Author: Robert Galen

Shhhhh. Be Vewy, Vewy Quiet!

Written by Robert Galen on . Posted in Articles. 1 Comment on Shhhhh. Be Vewy, Vewy Quiet!

ShhBeVewy1Hunting the Elusive Agile Customer

I can’t help being a fan of Bugs Bunny and other Looney Tunes characters. One of my favorites is Elmer Fudd, who is inspiring me for this post. Along with attendees from a workshop I just delivered in Dallas.

I deliver quite a few agile workshops. There are some questions that inevitably come up in each session-no matter what the workshop topic. One of these is related to the agile customer, call them the product owner or stakeholder. No matter what we call them, the question always surfaces around how to better involve or engage the agile customer in the activities of the team as they develop working software.

There seems to be a tendency for them to want to ask for a deliverable in the beginning of a sprint and then walk away until the end. Imagine that? Apparently many teams have lost sight of their customers and are looking for ways to inspire them to return. To that end, I offer eight ways to engage your agile product owner

  1. Deliver What They Ask for
    Well duh, this one isn’t that insightful. I disagree. I think as a discipline we more often than not deliver what we think they need. Instead, we need to listen deeply to our customer and deliver what they want…and perhaps a wee bit more. We show them that we care about their business needs and are willing to be servants to their perspective-delivering high value features. We also show them that we are active consumers of their feedback-leading toward real-time adjustments in functionality.
  2. Find a Good Example and Leverage it
    They say that a picture is worth a thousand words. I think a solid example of what a good agile product owner “looks like” is worth a great deal more. Find a PO in your organization that is performing well in the role and try to “tag team” yours with them. Use their practices and approaches as examples, but be careful to not turn it into an unhealthy competition. Even encourage your product owner to attend the other team’s activities. For example, backlog grooming or sprint demo preparation and delivery as a means of gaining new ideas and approaches.
  3. Ask, Show, then Ask Again…and Again!
    Engaging the customer in the incremental development of high priority features can literally be intoxicating. Perhaps not at first, but as you continue to deliver on agility’s promise of high value first, it will naturally draw them into the development tempo and rhythm of the team. So keep asking them to evaluate your progress to-date in narrowing down to story acceptance. And always keep your eye on the goal for each sprint or iteration from a business perspective.
  4. The Great Reveal
    Don’t forget the power of the sprint demo or review. Gaining a broad audience, showing working software and gaining feedback in a transparent forum is not only exciting, it’s efficient too. Remind your customer about the “Great Reveal” coming at the end of the sprint and how you need their engagement to make it successful. In fact, remind them that they have a responsibility to help conduct the preparation for and delivery of the review.
  5. Don’t Forget, it’s Their JOB
    Some of my earlier suggestions are simply using the properties of agile teams to draw the customer into engaging with the team. It’s the WIIFM part. But there’s another reason for them to engage; it’s their job and they have a responsibility because they’re a member of the team too. Don’t forget about the “responsibility card,” because every member of an agile team needs to effectively engage with their team.
  6. Demonstrate the Team’s Creativity
    One of the hidden treasures of a well formed agile team is that they don’t simply deliver on what you asked for. They’re not by-rote execution focused. Instead, they’re the creative partner of the product owner in solving the challenges their customers are facing. They understand the root customer needs and work very hard to deliver creative solutions that solve their problem. They’re not simply checking the box on a requirement. This creativity, when exhibited, will draw the customer towards you because you are solving their problems, their real problems…creatively.
  7. The Power of Being a TEAM
    Sometimes the Customer is too busy, or on the road, or engaged with more outwardly facing work. What to do here? Whine, complain? No! Help your team member. Work with them in preparation for their trip to ensure you have a surrogate in place for engagement. Pre-vet your ideas with them en masse and gain their early, condensed feedback. Prepare to remote them in for reviews at inconvenient off-hour times. In short, do everything you can to enable their engagement by taking joint ownership.
  8. Last, but Certainly Not Least, Leverage Your Retrospective
    I saved a goodie for last!. Each sprint’s retrospective is the place to discuss team improvement around results, process, approaches, issues, challenges, etc. It is a safe place, reserved just for the team, to surface their biggest challenges and to discuss ways and means for facing and resolving them. Move relentlessly  towards delivering high value work in a truly agile way. If you’re having engagement challenges with your customer, engage them in the retrospective. Don’t make it personal, instead speak to the team impacts and as a team brainstorm alternatives for improvement.

A fundamental success criterion for successful agile adoption is having engaged customers and product owners. Based on my informal polling when I’m teaching and coaching, we still have a huge challenge in successfully engaging customers with their teams.

I hope these ideas have helped in spurring ideas for how you can create more cohesive teams that draw their customers into the fray, making them a strong part of every iteration and each incremental release. If you have your own practices that have helped improve customer engagement, please add them to this post as a comment. I hope to get some great ideas!

 Don’t forget to leave your comments below

I’m Tired of Business Analysts Being Left Out of Agility!

Written by Robert Galen on . Posted in Articles.

I was at the Better Software & Agile Development Practices conference a couple of weeks ago. It’s put on by SQE and is one of the better software development-centric conferences in the country. This year they added an entirely new Agile Development Practices conference to run in parallel with the original. In keeping with that spirit of change, they also added some conference-in-a-conference sessions focused on agile testing, agile leadership, and something new this year-a two-day Agile BA track.

I didn’t realize they’d done that until reviewing the conference program while flying out to Vegas. And it struck me that it’s about time we start addressing the BA community more formally in our agile training venues and efforts. I used to think of testers and project managers as the two groups most left behind in agile evolution, but unfortunately I think the BA community has surpassed it.

I want to spend time in this post sharing some opinions and insights into the folks leading the way to assist BAs in their agile adventures. I hope you find the references useful.

People that Matter

So who are some of the folks making a difference in the agile community with respect to BA subjects? Ellen Gottesdiener and Jeff Patton come to mind as two thought-leaders who are making quite a difference. Ellen’s roots are more settled in traditional requirements management topics. She wrote what I consider one of the seminal works when it comes to running facilitated requirements workshops in the book Requirements by Collaboration. And she did this before much of the hubbub surrounding agility emerged in the community. To this day, it is incredibly applicable in traditional but equally in agile environments in running requirement workshops or User Story writing workshops.

Ellen is actively extending her reach into the realm of User Stories and agile requirement elicitation in-the-large or at scale, which is an oft missed focus in most discussions.

Another clear leader in this space is Jeff Patton. Unlike Ellen, Jeff has taken a new track into the space. He’s been focused on UI/UX design challenges and has translated that overall interest into User Story mapping and other broad-brush approaches for envisioning products via User Stories. This is an evolution from Alistair Cockburn’s Blitz Planning technique that helps to map User Stories across the depth and breadth of user interaction, business needs, and technical execution details.

An incredibly common challenge facing agile teams is seeing the Big Picture. Jeff Patton is leading the way in helping teams understand the broader landscape.

And what about Testing?

In the testing space, Lisa Crispin and Janet Gregory have written the definitive work on agile testing – Agile Testing. You need to keep in mind that collaboration is a key principal in agile contexts, so everyone works together. There’s a strong connection between the BA role and the testers on the team-mostly in the area of defining User Stories and refining their associated customer acceptance tests. I’d highly recommend adding this book to your library and paying attention to anything Lisa and Janet write about in the community, as both are relatively prolific.

One final point here is a trend to pay attention to. It’s the notion of Acceptance Test Driven Development (ATDD) and/or Behavior Driven Development (BDD). These approaches focus on crafting acceptance tests in tooling so that they are human readable and understandable, but still drive automated testing within your systems. It turns out that this combination creates a state of “executable requirements” that is incredibly collaborative and powerful from a BA perspective. A leading test voice in this space is Elisabeth Hendrickson.

So, Go Learn about Agile!

I often hear from BA’s that their growth opportunities are limited-often they feel stagnant in their roles with limited options for growth and advancement. It will take quite a bit of effort on your part and you’ll need to find chances to practice your chops, but agility beckons with a wide variety of opportunities. The thought-leaders listed above are a very good place to start…so happy learning!

Don’t forget to leave your comments below

Attacking Technical Requirements in Agile Backlogs

Written by Robert Galen on . Posted in Articles.

I was sitting in a meeting today where we were trying to capture architectural requirements for a popular SaaS product. There were mostly architects (software, network, and hardware) in the room and myself.

We started out talking about critical components of our existing system and how our current coupling made us more fault intolerant than we needed to be. Component cohesion, dependencies amongst specific components, services and systems was one of our most challenging concerns.

We began tackling our Product Backlog development by simply listing functional changes we wished to make. For example, we wanted to realign our authentication scheme to more align with customer groupings than a singular customer database. This would allow us to segment our customers in various models that would allow for smarter administration, group handling, and independent scaling.

It struck me in the meeting that these weren’t well-formed backlog items at all, as they were too narrowly focused. The other thing we were doing was aligning it with our technical intentions and with our challenges. So essentially, we were coming up with a wish-list of technically-driven product enhancements. Which is nice to have, but not truly a well crafted backlog. So, what weren’t we doing?

Start with the Business Perspective

Even though this was arguably a technical exercise, we should have started by driving them from a business perspective. Determining what sorts of customer problems were we trying to solve. What was the overall scope and impact of those problems-so order the work from a business perspective. Minimally this should be captured in a clear set of goals.

When you’re considering technical changes, clearly articulate the cost as well. Is this truly a necessary change in scope, function, and behavior? Run a gold-plating check to ensure that it’s truly required vs something simply nice to have. Clearly we should have invited business-facing folks to the meeting to serve as a customer-facing foil for our technical discussions.

Think in Terms of Delivery

We initially began prioritizing simply by what we thought were the most important or most sensible things to implement early on.  Quickly though, it dawned on me that we needed to think of how we would couple feature sets together from a customer delivery perspective.

How would these changes be packed? How would the new features partially or fully replace the existing features? Was the upgrade path clear? And was it simple and easy to understand?

When forming your technical backlog, think in terms of bundling, delivery and even documenting your work. Considering these aspects will significantly help you order the list, but also bundle work into clear and valuable themes or chunks.

Think in Terms of Testability

Another perspective that is helpful comes from simply thinking of how you’d test the deliverables. Testing coverage is one area to consider. How would you drive, end-to-end functional testing along the way while developing the backlog? How long would the testing be for each phase of the delivery and is that the most time/cost effective approach?

This focus on testing efficiency, how to prevent overly redundant testing, and build a testing strategy that aligns with the construction strategy is critical to represent in the workflow represented in your backlog.

Let Things “Cook” for a While

Quite often we want to make an immediate decision. We have passionate discussion and healthy debate. Usually a few voices are louder than others and then a “final” decision is made on the backlog. General enthusiasm then drives immediate action.

I’d prefer to let the backlog sit for a bit. Allow folks to stew on the details and think about the ordering-getting team members, technical and non-technical, to review the backlog and refine all aspects of it.

Remember that each backlog item needs some notion of doneness or acceptance associated with it. This helps to clarify the focus. This time can allow folks to refine the backlog from that perspective as well.

Finally, How About Working Code?

A final consideration is to not develop a technical backlog in full detail. Instead, develop it in terms of epic stories and develop some clarity around a single deliverable. Then, instead of hammering on the backlog, hammer out some working code that instantiates those important aspects of the backlog.

You’ll gain a sense of confidence and knowledge by doing this. You’ll also gain insights into the cost of execution that you can leverage in sizing and valuating subsequent work.

Technical backlogs are often attacked differently than functional or feature-rich backlogs. I think this is a large mistake many make. Hopefully this post has helped to broaden your approaches.

Don’t forget to leave your comments below

Embracing Agility – Your Best Bet for Business Analysis Skill Development!

Written by Robert Galen on . Posted in Articles.

If you’ve been reading my blog entries at all this year, you’ve realized that I’m fairly enthusiastic about the agile methods. I think one of the most misunderstood aspects of agility and the methods themselves relates to their nature. You know, they’re really not methodologies. Certainly not in the same sense as heavily documented Waterfall and its variants or RUP or Spiral or any other traditional methodology.

Instead, I liken them more to Lean and other improvement oriented thinking tools and approaches than a specific methodology. They also gather concepts and patterns from historical software development practices that seem to work well , e.g,  unit testing, continuous integration, refactoring, and pair-programming.  That’s why I almost always hear the following from my students in my classes: “So that’s agile. I’ve been doing much of that for most of my career. It seems that the packaging is the key…and the mindset.”

I find myself universally agreeing with the students’ perception. It’s about a mindset that transcends “agility” and leads towards outstanding performance and growth as a technologist. Let’s explore some aspects of that…

Self-Directed, Empowered, and Accountable Teams

If you get the chance to join an agile team as a BA, jump on it. It will give you a chance to operate as a true, collaborative team member. Leadership opportunities will surface and you’ll get plenty of opportunities to show off your chops in a very visible venue.  High performance is what matters in these teams, and low performers can’t “hide” from the team. It draws out excellence.

In these teams words, written or otherwise, mean very little. What counts is delivering on commitments with working, demonstrable software. It’s about real delivery! Not in hours worked, but in raw productivity and creative solutions to the teams’ problems.

Focus on Quality and Improvement

As part of their career evolution, BAs need to become much more “quality literate”. Dive deeply into understanding the techniques for building in quality, for example reviews and inspections. What are the business cases behind them? The pay me now vs. later trade-offs in software and begin to challenge poor decision-making.

Partner with the testers. They are often underestimated and underutilized within most teams.  Yet, effective testing is as challenging a technical exercise as architecting or modeling any software system. Dive-in and test the software with a wide-variety of manual techniques, and learn how to test effectively. Even jump-in and do some simple automation. It will give you yet another perspective in your journey!

And when you attend retrospectives, have the fortitude to engage your team on continuous improvement. Call them out on the practices that need improvement and, during each iteration, demand focus on those improvements. Then celebrate each and every improvement!

Transparency and Feedback

There is tremendous power in making all of our project dynamics totally transparent to everyone.  First, it takes courage to “tell it like it is”. It also opens the door for feedback from all perspectives. That old notion of not raising issues without solutions doesn’t hold any longer. We’d rather get early visibility into the issues so the entire team can engage in solutions.

And don’t get defensive. If you get confronted on a mistake, take the time to explain the context and thinking processes behind your decisions. Be open to corrective action discussions without appearing defensive. In fact, become more comfortable with failure. Failure is good in agile teams; we simply want to fail early, small, and catch it quickly. This leads towards the necessary adjustments to get things “back on track”.

Generalist Mindset

I’ve seen so many software development roles (programmers, architects, testers, BAs, project managers, etc) take a very narrow view towards their roles and their work. Very often they create a narrow silo of responsibility that they ‘own’ and everything outside of that is “someone else’s’ job”. That often extends to their knowledge as well. They might only understand one narrow slice of their applications and not have a broader brush view.

In agile teams this view is highly discouraged. Not so much by management, but by the very definition of a self-directed team trying to meet their goals and objectives. The broader your view, the more  flexibly you can operate within your team and deliver the goods.  Oh and by the way, the more valuable you become!

Wrap-up

Don’t let anybody tell you that agile teams are easy. They are not! To me they’re sort of a Boot Camp for personal growth and improvement. They provide opportunities for becoming more open-minded and trying new approaches. They also provide opportunities for thinking outside your traditional box and roles. If you’ve got the courage and persistence to truly want to improve, agility will provide you with incredibly diverse opportunities to learn, be recognized, and advance!

That is…if you embrace It!

Don’t forget to leave your comments below

“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