Skip to main content

Tag: Team

Agile BAs… Don’t Go in without TOOLS!

Written by Robert Galen on . Posted in Articles. 1 Comment on Agile BAs… Don’t Go in without TOOLS!

In my last post I discussed the role of BA as it relates to working within agile teams and tried to explain what you can and should do as part of your team. One of the comments I received related to the role of User Interface Designer in agile. I had implied a complementary role in the post and the reader was looking for a bit more information. I thought it was a really good question and it’s led to this follow-up post…

Applying user interface design in agile methods is one of the leading challenges right now within the agile community. Since it’s an early-on activity, as is any design activity, the notion of sprinting till your done-continuously delivering working software iteratively doesn’t seem to engender much in the way of design.

Thus the challenge…

What design practice has done is encourage the agile folks to slightly reconsider their models. For example, within the design space, it is often quite reasonable to do design work within an iteration, that will only be ‘used’ in subsequent iterations-say the next one or two. This sort of look-ahead from a design perspective is required as the team can rarely implement the work within the same iteration where the design was explored and defined.

The trick is to not look-ahead too far. If you do, you fall into the waterfall trap of designing everything in advance, before you’ve actually gotten a few lines of code to work. (Something we agilists describe as BDUF – or Big Design Up Front and a common anti-pattern of agile development).

So this creates a need to oscillate or balance activities within your agile teams between some look-ahead tasks such as architecture, analysis, and design and then transitioning to coding and testing. I think the best agile teams ‘get’ this balancing act early on and understand that they have to work on both sides of the equation.

There are a couple of tools within the agile arsenal that foster look-ahead. I’m going to speak to a few. While they’re often ignored by the more purist-focused agile methodologists and teams, they are indeed a quite viable tool-set for looking before you leap into iterations.

  • Chartering. In the same spirit as traditional project chartering, agile chartering focuses on developing the why behind the project. Usually it targets the business case for the project including: target customers, vision for the project, ROI information, budget details, high level scope targets, team and capabilities information, and definitions for success – usually including a schedule or date target. The charter should serve to energize the team by sharing the why it matters behind the project or effort.
  • Research Spike – User Story. At times you really don’t know enough to write a solid user story. Usually the gap is in technical or design experience and what you really need is a little time to “play around” with things to gain a better clue. The output of a research spike isn’t working code. Instead it’s knowledge – usually in the form of architectural design details and a refined set of user stories destined for implementation in a later iteration. As a rule of thumb, I usually see 20% or so of stories in my backlogs that warrant a spike to gain more clarity.
  • Iteration #0 or Sprint #0. Quite often agile teams simply dive into their work, iterating before they have a clue to where they’re going. For some projects, this seems to work and the team figures out their direction along the way. For many others, this is a disaster. Jim Highsmith coined Iteration 0 as a term in his Agile Project Management book. It’s defined as a first/early set of iterations that are focused more towards getting ready to begin building a product than on the actual construction. A wide variety of work can be encompassed in a Sprint #0 including, architectural definition, requirement analysis and backlog preparation, design work, setting up office space and building the team, training, project chartering, group planning activities, etc. The caution is not to allow your Iteration/Sprint #0 to extend too long.
  • Blitz Planning. Alistair Cockburn defines Blitz Planning as part of his Crystal agile methodology. Crystal hasn’t achieved much popularity, so you probably haven’t heard much about it. However, there are techniques within Crystal that are quite powerful and this is one of them. In Blitz Planning you engage the entire team and key stakeholders in defining the overall plan of attack for the project. This includes developing the overall feature set, work tasks, dependencies, identifying key milestones, and such. At the end of a day or more of collaborative planning, you end up with a detailed, end-to-end mapping of the work. This includes when and how you’ll be doing analysis and design in order to effectively drive your agile iterations during construction.
  • Story Mapping. Jeff Patton is one of the champions of this technique and is actively refining it. What often happens in agile product backlogs is that the individual stories often obscure the big picture and overall direction a product is taking. Story mapping strives to connect individual stories into the themes and feature interactions that your real customers will be using. Typically, it’s a low-fidelity technique where story 3×5 cards on a way are elaborated and refined from the customer workflow and user interaction points of view. It often identifies gaps and helps to prioritize what should be implemented in what order.

For those of you who thought that agile did little in setting the stage in advance of the work, I hope this post and the tools open your eyes to a different perspective. While the agile methods do take a lean, iterative view towards software construction, many projects need some initial vision setting. I also think these techniques can be mapped, to good effect, to the more mainstream methodologies. Happy exploring!

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].

Think “I” instead of “We” when Talking about Your Business Analyst Career

Written by Laura Brandenburg on . Posted in Articles.

Picture yourself in an interview for your dream business analyst job. You are confident in your qualifications. You have prepared for the interview by researching the company, the hiring manager, and anyone else with whom you are meeting.

The manager asks you a few questions about your experience with a focus on business analysis. You answer confidently about how your team accomplished exactly what they were asked to do. You give an example. But the manager still looks at you a bit puzzled and probes for more information. She or he doesn’t seem to fully trust your answer.

One possible cause of this situation is that you are using “we” in your answers instead of “I”. You are a team player. You know that as a business analyst you help teams achieve great results. You focus your answers on what the team accomplished. This is a great way to look at your day-to-day work. But in an interview situation, the hiring manager is interviewing you not your team. Answers talking about “we” seem vague, are ambiguous, and can leave the impression that you are avoiding the questions.

From my own personal experience as a hiring manager for business analysts, one particular candidate among the many I interviewed with the “we” tendency, stands out among the rest. I share his story to help the other candidates out there who may unknowingly be facing his same challenges.

The candidate’s answers to my questions revealed a strong team orientation and other professional qualities that I respected and desired, but when it came to his BA qualifications, I couldn’t quite nail him down. In answer to every question about every project, he started the answer with “we”. We created a requirements document. We came up with an elegant solution. We implemented a successful project. We, we, we.

Truly liking the individual, I started probing and prodding then finally asked, “I understand what your team accomplished and that’s great. It’s important for me to understand what you contributed. What did you do, specifically, to help the team accomplish that success?” Unfortunately the candidate failed to come up with an answer and defended his “we” stance: “My contributions were only part of the team. That success was impossible without the whole team.” Although my gut said he was a good candidate for the position, I couldn’t validate his BA qualifications with any hard evidence. He was not hired.

I want to help you avoid this same shortfall. The difficulty is that his answer is true and valid. We accomplish more as part of a team. No matter how we think about it, we are not solely responsible for the outcomes we achieve as part of a group. But the career-defining questions remain unanswered: What did you do? Why should I hire you? Why should I believe that you will make a contribution on one of the teams in this organization?

In preparing to speak about what your team accomplished and what you contributed to help your team succeed, it can be helpful to keep a catalog of your projects and accomplishments. For example, let’s consider a requirements document. There is no doubt that significant project documents, such as a business requirements document or functional specifications, are the result of contributions from many individuals. When evaluating this experience for your contribution, think about the following activities:

  • Did you author the document? Alternatively, did you edit a document started by someone else?
  • Did you solicit feedback on the document and collate comments and reviews?
  • Did you elicit the requirements and ask the questions that ensured the document was complete?
  • Did you facilitate the meetings, pointing out disparate input or conflicting requirements?
  • What else did you do?

While the document you produced is the collective output of the team, it’s likely you had a very distinct role in that accomplishment. Catalog your specific contributions and be prepared to speak about them in detail.

Alternatively, if you were part of a BA team, you might consider quantifying your part in that team. For example, if the team collectively produced 50 use cases, maybe you drafted 20 of those use cases and provided critical feedback on the other 30. Can you think of an example where your feedback addressed a problem no one else had considered? Maybe you owned a part of the review or approval process. Maybe you owned the use case list and model.

Another way to think about this concept is to answer the following question: What hole would have been left if you had been plucked from the team? Looking at the team trying to achieve its objective without your efforts, analysis, and influence can help you see the situation with a fresh set of eyes. It can help you identify your slice in the team’s overall effort.

It’s also possible to use this approach to explaining your experiences while still showing you are a team player. One of the line items on my resume talks about a career experience from my early days as a QA engineer. I entered into a situation where developers across two different locations were often at odds with each other about the root cause of defects and who should fix them. I partnered with the developers from the other location, began testing their output directly, and helped drive more effective communication between the groups.

In my resume, I speak about breaking down communication barriers to reduce the length of time it took to resolve a particular category of defects. Of course, I did not single-handedly fix the issues, nor was I the only contributor to the improved success of this group of people. Every member of the team had a critical role in that improvement. But I am confident in calling myself out as the catalyst and talking about my role in bridging the communication gap, an accomplishment that helped carve my path into the business analysis profession.

So I ask you. What do you have to say for yourself and your career? Are you a career casualty to the ambiguity of “we”? If so, I challenge you to start a catalog of your recent projects and think long and hard about your contributions. This is a great step to take to advance your business analyst career.

Don’t forget to leave your comments below

What do BAs “Do” within Agile Teams?

Written by Robert Galen on . Posted in Articles.

For the past several posts, I’ve been focusing on user stories within the context of agile teams-how to write them and the role they play in agile development. This month I wanted to switch gears a bit and talk about the role of the BA within agile teams.

The first point I really want to make is not BA role specific but focused towards the general role of the agile team member. You see roles need to become much less clear or constrained within agile teams. Sure, a developer is still a technical role and will be mostly writing code, but that doesn’t mean it’s the only thing they can and should be contributing to the team.

There’s quite a debate in the agile community about generalists vs. specialists as team members. Clearly the more general you are, for example a tester who can write or read code or a BA who can test, the more flexible your contributions are within the agile team.

The pushback within the community is based on folks taking this idea to its (unintended) extreme, for example developers who believe we’re asking them to morph into full-time testers or vice versa. So, in general, pun intended, you should not view yourself narrowly as a business analyst, but more broadly as a team member who has strong requirement analysis skills against an even broader back-drop of capabilities that you often bring to bear within your team.

So, what specifically is the BA role within agility?

It starts out the same as it does in your existing role. You are a customer advocate and liaison. You have tremendous experience in the analysis and capture of critical system requirements. You have broad collaborative and observational skills. Often, you sit down with a wide variety customers, stakeholders, and constituents and gather and define requirements from a wide variety of angles.

But within agility there is so much more you can do along the lines of the following:

  • Product Backlog Partner. Clearly the BA role focuses on requirement definition & refinement. Using Scrum as our terminology backdrop, it implies working closely with your product owner, customers, and team members to construct and refine the backlog. Remember, in the agile methods all work should be defined on the backlog, so it’s not simply feature-based. You need to be comfortable defining user stories that represent task work as well.
  • Fostering Team Collaboration. BAs often become a liaison between the product owner (customer) and the team. They foster an inclusive view that brings team members together to better design and build customer-focused solutions. The methods sort of oversell collaboration as a natural occurrence. I have the view that it needs to be encouraged and often championed. BAs can clearly serve as this champion of collaboration amongst team members. I’ve often seen BAs adopt a facilitative role within their teams, facilitating effective meetings, information sharing, and problem solving.
  • Driving Quality. Working with your product owner and testers, you help to define, refine, and even execute user story-centric acceptance tests. Often, you’ll view the execution of features from a more holistic, end-to-end usability view that is so important to the customer. Verifying that the software is as simple as possible while still meeting the customer’s usability and core expectations.
  • Maintaining a Value Focus. Taking a page from Lean Thinking, the agile methods are extremely value and cost centric. Often you’ll see Scrum teams that focus not only on priority to determine what is worked on first, but they also try and determine the value (ROI) for a given feature set. BAs can often help facilitate this value-based analysis between team and customer. They can also help guide the team towards Minimal Marketable Feature sets (MMFs) that implement predetermined value, delivering early and often.
  • Demonstrating Results. As a full-time member of your agile team, your true focus is towards delivering small slices of end-to-end functionality at the end of each sprint. Be willing to serve as a voice of your team in these demonstrations. Truly understand how the delivered software works and how to effectively demonstrate its value. Don’t be afraid to step into the limelight and demonstrate working code as part of each sprint review.

Often I think of the US Army recruitment commercial, “Be All You Can Be”, when I think of roles with agile teams. As an Agile BA, you should grow your skills horizontally and fearlessly contribute wherever you can within the team. Your teams and customers will value you for it!

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].

12 Rules of Delegation for Business Analysts

Written by Richard Lannon on . Posted in Articles.

Delegation is one of the most important skills. Business analyst team leaders and other technical professionals, managers, and executives all need to develop good delegation skills. There are many rules and techniques that help people to delegate. Good delegation saves money and time, builds people and team skills, grooms successors and motivates people, and leads to successful projects. Poor delegation sucks! Ask any employee. It causes frustration, demotivates and confuses people and teams. It is important to develop good delegation skills.

These 12 rules of delegation should help you out.

  1. Delegation is a two-way street. That’s right! Delegation is meant to develop you and the people you work with. Consider what you are delegating and why you are delegating it. Are you delegating to build people, get rid of work you don’t like to do or to create an effective team?
  2. To be a good delegator you need to let go. You can’t control everything so let go and trust the people you work with. Hand over those tasks to other people that are stopping you from reaching your full potential.
  3. Create a delegation plan. Use a delegation matrix that shows your people and the main task components and how you can develop your people and get the work done. This will help your people understand the expectations being set.
  4. Define the tasks that must be done. Make sure that the task can be delegated and is suitable to be delegated. Some things you have to do and others can be done by someone else. Be clear on what the task is and is not. People like clarity when being delegated to. So ensure you are clear. If you are not clear your people will not be and you will be disappointed. Worst, your people will feel like failures. Not cool!
  5. Select and assign the individual who should take on the task. Be clear on your reasons for delegating the task to that person. Be honest with yourself. Make sure you answer the question what are they going to get out of it and what are you going to get out of it? Think of it as listening to the radio station WII-FM (what’s in it for them). It’s a good motivator.
  6. Make sure you consider ability and training needs. The importance of the task may need to be defined. Can the people you’re considering do the task? Do they understand what needs to be done? If not, you can’t delegate it to them. If resources are an issue, sit your team down and move things around or develop a mentoring-support program that enables your people.
  7. Clearly explain the reason for the task or work that must be done. Discuss why the job is being delegated and how it fits into the scheme of things. Don’t be afraid to negotiate points that are discussed when appropriate. Don’t say it is because we are told to do it. For your people to own the task you must own the task. Reframe and rephrase it so you have ownership.
  8. State the required outcomes and results. Answer questions like what must be achieved, what the measurements will be, and clarify how you intend to decide that the job was successfully done.
  9. Be prepared to discuss the required resources with the individual and team. Common challenges arise with every person and team including people, location, time, equipment, materials and money. These are important concerns and should be discussed and solved creatively. However, sometimes it is simply as it must be done. Be prepared.
  10. Get agreement on timeline and deadlines. Include a status reporting feature to ensure things are getting done. When is the job to be done? What are the ongoing operational duties? What is the status report date and how is it due? Make sure you confirm an understanding of all the previous items. Ask for a summary in their words. Look for reassurance that the task can be done. Address any gaps and reinforce your belief in the individuals or teams work. They need to know you trust them.
  11. Remember the two way street, well it is most likely a multi-directional intersection. Look around and support and communicate. Speak to those people who need to know what is going on. Check your stakeholders list and make sure you inform them what the individuals’ or team’s responsibility is. Do not leave it up to the individual team member. Keep politics, the task profile and importance in mind.
  12. Provide and get feedback for team members. It is important that you let people know how they are doing and if they are achieving their aim. Don’t get into blame-storming. You must absorb the consequences of failure, create an environment where failure is an opportunity to learn and grow and pass on the credit for success. Pay it forward if you can.

Delegation used as a tool develops you and your people. The better you are at delegation the better the people around you and your teams will do. It is part of command skills and should be used to let go and trust in your people. The difference between success and failure is often a matter of letting go and delegating.

Don’t forget to leave your comments below

Richard Lannon works with those people, organizations and enterprises that want to identify what’s important, establish direction and build business skills that will positively impact their bottom line. He can be reached at [email protected], 1-866-559-8126, www.braveworld.ca

Change Management; What Exactly is Buy-In?

Written by Kelly Burroughs on . Posted in Articles. 1 Comment on Change Management; What Exactly is Buy-In?

When it comes to change management, the term ‘buy-in’ is tossed around the office like a baseball around the diamond in a pre-game warm-up. It is a term used to indicate the need to convince everyone to get on board the change train, as it is destined for great things. But I find this term funny, because it indicates the change has already been decided, the train is leaving and I better get on or…well stay behind. And then we wonder why there is resistance to change.

But what if change was not something that was imposed on people, but was something they themselves came up with?

So many times I have worked on a project where a decision is made at an executive level, and then announced to the business with a fancy PowerPoint slide show, a few bullets about what the benefits will bring, and the overall concluding message of “we are doing this regardless, so you better get on board”.  And then we wonder why there is resistance to the change. But the fact is, if you make the decision to change without first asking the people the change will affect most, chances are pretty good there will be a defensive and resistant reaction.

One example that comes to mind is a company that decided to reorganize the entire organization without telling the employees until a company wide meeting was called one morning. Employees shuffled in, took their seats and found staring back at them, a man dressed up in a bear costume and fireman’s helmet, there to put out the ‘fire’ (and make the PowerPoint presentation). Needless to say, the reaction from the employees was not a good one (and going into the many reasons why might just be another article all on its own). In the end the meeting was not a productive one and, in fact, put many employees on the defensive about their job security and their role within the company. Everyone left more confused than when they had  arrived, and nobody remembered any of the benefits listed within the PowerPoint presentation (but will probably remember the bear costume for life!).

But what happens if you skip the fancy PowerPoint slide show, and get the non-IT folk to come up with the idea in the first place? Would there still be resistance?

People have a tendency to want to own things – whether it be their house, car, yacht, or the job they perform on a day to day basis. Because to many people a job is a set of daily routines and procedures they have become accustomed to doing on a daily basis; and more than that, have become very good at.  To then introduce change into that daily routine without consulting or involving them, is the equivalent of stealing their car from their driveway and trading it in for something new, without asking them. Now some people might be happy with a new car, but many people would resist the new car and want their old one back. Maybe they wouldn’t like the colour because they didn’t pick it, or maybe they didn’t really want the upgrade to a sunroof because they once had a bad experience sticking their heads through one. Maybe they just did not like the fact that the decision to get a new car was not theirs. And there is no difference with change in the workplace.  If you just suddenly take something away from somebody and replace it with something that you may think is better, you can almost be guaranteed they will find something wrong with it, and NOT think it better.

So then, how should change be introduced?

How about driving the change from a lower level? With so many change initiatives coming from the top of an organization, you constantly have a top-down channel of communication, which often puts those on the bottom on the defensive. How many times have we heard in reaction to a change: “Why do we need that? What is wrong with the way I do my job now?’ But what if what if those who would be most affected by the change were approached at the start and asked things like:

  • So what currently holds you up in your job?
  • Is there anything you do now that is completely manual?
  • Is there anything in the current process that you think should be changed which might make it easier for you to do your job?
  • Would you like to be involved in looking at new software for what you do?

Would they then see it as change, or would they maybe see it as something they can own, or do, to improve their jobs?

To me, getting others in the business to see the issues, own the issues and then, because of it, want to be part of the solution is the key to incorporating change into a company. It is surprising how often people are willing to be a part of projects, if they are just given the chance to get in at the start. But to be just told they are on a project, which ultimately affects their job, is often times a setback right from the beginning.

There will always be those who think making the decision and then showing the fancy PowerPoint presentation with the benefits of the solution is the answer to introducing change. But to me, change should never have to be introduced to the business – it should be generated upwards from the business. Getting people to realize the problems themselves, and come up with the solution themselves, will almost always work because people take pride in what they own and want to make their ideas work. Because remember; there is very little difference between ‘change’ and being ‘creative’. The only difference lies in where the direction comes from. You tell somebody to do something and they cringe at ‘change’, but if you get them to come up with the idea themselves they are ‘creative’, and will take pride in being so.

Don’t forget to leave your comments below

Kelly Burroughs is a Business Analyst/Project Manager for Halsall Associates, a professional services engineering company. She has several years experience in implementing larger scale technology changes into businesses, as both a business analyst and a project manager. She can be reached at [email protected].