Skip to main content

Tag: Agile

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

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]

How Can BAs Be More Strategic in an Agile Environment?

Written by Maria Horrigan on . Posted in Articles. 1 Comment on How Can BAs Be More Strategic in an Agile Environment?

As a business analyst working in the business area, I am finding myself more involved in the enterprise strategy arena and working across many projects. More and more, these projects follow an agile methodology. I’ve been traveling a bit lately and needed some reading material for my trip so I thought I’d revisit Sun Tzu’s The Art of War.

The Art of War focuses on strategy and planning and in an agile environment, there is much insight and wisdom BAs can gain from this sixth century BC Chinese General. Here are just six of his ideas that I think most capture the essence of agile as a philosophy and the core business analysis competencies I have been using on my projects, to help me adapt to an agile framework.

1. Discipline and Control of the Game – “…marshalling of the army in its proper subdivisions, the graduations of rank among the officers, and the control of military expenditure”¹. When I am presenting on Agile, one of the criticism I get from the audience is that Agile lacks rigor and discipline and is a more laissez-faire approach. I suggest to them that even though Agile fosters innovation and creativity, the project’s success is not the result of luck or a fortuitous accident, but rather the result of consistent planning and effort. On my projects, everybody’s role is clear and each knows what we need to do to get to the next stage or complete the next stream of work. My BA approach on Agile projects is iterative, as a team we learn and adapt as we go, but that doesn’t mean there is absence of planning and coordination.

2. Be Flexible and Run with Opportunities – “Avail yourself of any helpful circumstances over and beyond the ordinary rules. According as circumstances are favorable, one should modify one’s plans”¹. Sun Tzu was known as a master of controlling the game through leadership and discipline, but in this passage he is referring specifically to this need to remain flexible in changing conditions and be prepared to capitalize and follow up on an opportunity. This is the essence of Agile. When we commence projects, it is not possible to know all we can about the environment, the business and user needs. Requirements will change and evolve as we progress through the project and learn more about the situation and context. As a BA we must have a focus on continuous learnings and applying these learnings to the next stream or iteration is the key.

3. Act Fast to Avoid Fatigue – “Though we have heard of stupid haste in war, cleverness has never been associated with long delays”². Protracted campaigns can damage morale and resources and Master Sun suggests taking swift action to avoid the pitfall of expense and exhaustion. A number of years ago, I worked on a project that had already been going for two years when I joined. People were clearly tired and weary from the ‘battle” and project costs were blowing out. We regrouped and adopted an Agile approach. We had stand-up meetings every day within our team but we only engaged users when we had some progress in our work to show as these users and business groups were fatigued after two previous years of consultation with nothing to show for it. Within six months we had a working prototype from end to end, and a strong and committed BA and design team that rallied behind the Change Manager leading the project. It was important that we had “quick wins” early to keep the momentum towards our goals and manage the change process from “as is” to the “to be” state. Having a change manager to help facilitate and progress requirements through the various governance members was a big advantage.

4. Ensure Your Goals and Objectives are Realistic – “…by commanding the army to advance or to retreat, being ignorant of the fact that it cannot obey”². I think this really speaks to the heart of the user-centered design focus of many of my Agile BA projects. Master Sun warns that mistakes will be made if orders are issued from the safety of a far off court that doesn’t have experience of the combat situation. The business context and “big picture” strategy need to be mindful of the day-to-day operations. The people who are on the ground and know the capabilities of the current team and resources are the best source of knowledge for work shopping the business drivers, processes and gaps in order to uncover the business and user needs for your project. This is where BAs have a key strength and knowledge base. For example, once I have captured these needs, I always talk to the technical team to see if what the users want is realistic and possible (within out budget and capability). If there are sound limitations to what is possible, then I go back to the business and users and discuss alternate ways to achieve the same goal. Users then give me insight as to whether this alternate idea is practical. This iterative approach is critical to solving some of the more complex issues on the projects.

5. Employ the Right People for the Job – “… by employing the officers without discrimination, through ignorance of the military principle of adaptation of circumstances. This shakes the confidence of the soldiers”³. Finding the right people for the job is imperative. In Agile projects it is important to look at the essence of what the project is about and what problem it is aimed to solve and then decide what skills are needed and what patterns to apply. From this planning we then look at building the team. Of course you do not always have the luxury of being able to pick your team for projects, but if you set up an Agile team and draw from skilled resources across the organization, this is more likely to aid the success of your project. Reverse engineer the position; don’t just look at who you have and see if they will fit, find out what you need and then seek people with these skills and abilities. BAs bring many skills to the project and in Agile I have found that my skills of analysis are used beyond traditional requirements gathering. I have been involved in design, information architecture and business strategy workshops.

6. Adapt as Strategic Rigidity is Dangerous – “Water shapes its course according to the nature of the ground over which it flows; the soldier works out his victory in relation to the foe that he is facing”4. This emphasizes the need for fluidity and that to be successful, you must adapt. The business environment is dynamic and constantly changing and adaptation is key. As Charles Darwin stated “It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change”. As BAs in an Agile environment, you need to understand your user (primary, secondary and tertiary) and ensure that your processes and systems are developed with their needs in mind. When building user personas, start with a “skinny” view of this user and flesh it out as you find out more about their needs. Likewise, your business requirements will be “skinny” at the commencement of the project and will be elucidated more as the project progresses and each stream build upon the knowledge of what is working and what is not.

As an enterprise BA I am looking not just at my immediate project, but also how this work fits into the rest of the organization. Sun Tzu stresses the need to plan, find the right people, and give them resources and authority to execute those orders, choose a strategy and vary your tactics according to the situation. In looking at the essence of your projects, take the time to plan what you need in terms of skills, patterns to apply, things to do and things to produce and be flexible in your approach to adapt these to the project learnings as you progress, or the business needs or circumstances change.

References:

SunTzu’s Art of War, A 52 Brilliant ideas interpretation by Karen McCredie, 2008

¹The Art of War, Sun Tzu. translated from the Chinese by Lionel Giles, MA (1910), Chapter 1 – Laying Plans

²The Art of War, Sun Tzu. translated from the Chinese by Lionel Giles, MA (1910), Chapter 2 -Waging War

³The Art of War, Sun Tzu. translated from the Chinese by Lionel Giles, MA (1910), Chapter 3 – Attack by Strategem

4 The Art of War, Sun Tzu. translated from the Chinese by Lionel Giles, MA (1910), Chapter 6 – Weak points and Strong

Don’t forget to leave your comments below

Maria Horrigan is an experienced business manager, IT strategic planner and information and communications specialist. She has over 10 years senior management experience within the pharmaceutical industry, not-for-profit and Government. As a principal consultant, Maria is an experienced information architect, senior business analyst and IT strategic analyst and provides advice on developing system requirements with a focus on information architecture and user-centred design, to ensure appropriate IT systems are intuitive and usable. She is a senior practitioner and a well-known Australian speaker on communication, user-centred design, and business analysis. She has experience managing large federal government contracts and project management of large scale business system implementation, systems planning, and analysis and change management. She has a reputation for innovation, managing change, driving strategy implementation and successfully delivering programs. Maria is a Board member and Vice President of Women in Information and Communication (WIC).