Tag: Career

It’s Not Personal – It’s Only Business

Written by Kristopher Goins on September 4, 2015. Posted in Articles.

As business analysts we’ve typically all been exposed to the process of a document peer review. A well-structured and dedicated peer review process is not only a sanity check to maintain healthy documentation practices; but also be a great continuous training exercise for business analysts to learn new ways of approaching their documentation and also learn from the seasoned expertise of their peer counterparts. It provides a pulse of where improvement can occur across your enterprise and provide strong evidence for where strengths exist.

Business Analysts are by-and-large very meticulous about document review and will find the smallest error or inconsistency and use it to pull the document apart methodically piece-by-piece; leaving nothing but the draft version smeared in redline corrections and comment bubbles in the margin. It’s kind of a gift we all have. The ability to find fault in a document not our own is far easier than writing a document in which others will not find fault.

Don’t Take it Personally

One of the most common responses to peer review critiques I have encountered in my experience is the frustration and outrage caused by the document author believing that the review comments are in some way personal. As business analyst professionals, we can never assume that document criticism is a personal attack or that the critique has been made as some form of vendetta for a previous transgression; known or unknown. As a business analyst, this is an unhealthy practice that will only cause constant frustration and tension between you and your peers and adds no value to the team or your advancement in business analytics. Opportunities for improvement come in many forms; peer review is one of those forms; even if the comments sometimes reveal difficult truths about documentation weaknesses.

A Real-Life Example

When I first started, I was so eager to do a good job and prove that hiring me for a business analyst position was the right move; I worked tirelessly on my first assignment, dotting every ‘i’ and crossing every ‘t’. When I sent out my first document for review, I thought I did pretty well and was quite proud of the work I had done; until I got the comments back from my peers. Some were very positive; others were simply clarification questions and others were (what I thought at the time) downright mean. I received some incredible advice from my then boss (now colleague) who suggested I reassess and think about it not from my perspective, but from the reviewer’s perspective. I did this and realized that none of their comments could possibly be personal, and I was being completely irrational. I reevaluated my document and addressed the comments. Some I agreed with and corrected and others I responded to with justification as to why they should not change. My own ego, vanity and desire to do well blinded me from seeing the validity of the contributions of others and gave me the initial feeling that I had somehow failed.

How Peer Reviews can help

Now that I have been in the analyst realm for a while, one of the things I look forward to with having my documents reviewed by peers is the experience and insight I gain from others who may have been at this game longer or have a different background or perspective that can add to my own and provide me with additional information to add to my documentation. Documentation audiences range in comprehension, so the more concise documentation is, the less misinterpretation will occur with the content of any documentation. In my years as a business analyst, systems analyst and solution analyst, I have never seen a first draft document go through a peer review without encountering some kind of comment, question, grammar correction or suggestion to content. No analyst is perfect, and no document is ever going to be perfect. Someone will always have something to say about the document; whether it is content, layout or even something as trivial as font type, there’s always a way to improve or something to elaborate on and there will always be someone who has something negative to see; even if it is minor.

How to set yourself up for success

There are a number of steps we can take as analysts to avoid those minor criticisms and provide confidence that our documents are of high-quality the first time out; while maintaining the understanding that comments and criticism are inevitable.

Spell Check – If you’re using MS Word, it’s a button…Just click it.
Grammar Check –MS Word has a feature; it’s not entirely accurate all the time but catches common mistakes.
Make a checklist of common things people forget to change in their documents and start checking off items. Some common mistakes are:
1. Version Number
2. Page Numbers
3. Revision History
4. Table of Contents
5. Formatting
Consider your audience – Sometimes you have to tailor your document to a different level; whether higher or lower. What type of voice are you using; passive, assertive?
Put your document through the process of questioning every requirement. Is it clear? Is it unambiguous?
Avoid using acronyms without first defining them
Do your process flows match your requirements (if applicable)
Look at your document objectively
9. Put it down for a while, do something else and revisit it. A fresh mind can lend perspective

There is no definitive list that we can put together than can aid us in writing a perfect document. While we can review our work over and over again, we will always have the potential of missing something. Sometimes it will be something so minor it’s hardly worth mentioning and other times it’s a valid contribution we must consider revising our documents, making a higher quality, more concise final product. We must remember that there is always going to be someone with more experience or someone that is a radical grammar cop or even someone who doesn’t quite understand and needs clarification. We can always do things better, and we must continuously find new and better ways to get through our work and find success. Learning from each peer review session and remembering those comments and critiques for the future, shows that we are improving and making an effort to evolve as business analysts. I am sure there are plenty of things forgotten in this article, and this topic has been well lamented in the analyst community. Through all of the perils that a document review session with our peers can present us with, we cannot allow ourselves to believe that it is ever personal. It’s not personal, it’s only business.

Nine Key Skills That Every Good Business Analyst Needs

Written by Abbie Cockburn on July 22, 2015. Posted in Articles.

Being a successful Business Analyst means you have to have a variety of different skills and be adaptable to a changing environment. Every Business Analyst will bring their unique blend of skills and experience to the role, of course, but I’ve highlighted below what I think are the most common skills that a good BA will need. Feel free to add in the comments any other skills that you have found helpful in your BA career.

1. Understand your objectives.

Being able to interpret direction is important. If you don’t fully understand what and, more importantly, why you are being asked to do something, there is a risk that you won’t deliver what’s required. Don’t be worried about asking for further information if your brief isn’t clear.

2. Good verbal communication skills.

It is essential that you are a good communicator, regardless of the method of communication. You must be able to make your point clearly and unambiguously. It is also important that you know how to ask insightful questions to retrieve the information you need from stakeholders. For example, if your stakeholder isn’t a technical specialist you may need to ask your questions in plain English – avoiding jargon and acronyms. Being able to communicate information at the appropriate level is vital – some stakeholders will need more detailed information than others.

3. The ability to run stakeholder meetings.

Although using email provides a useful audit trail, sometimes it is not enough to communicate with stakeholders via email. Don’t underestimate the value of face to face meetings to discuss problems in more detail and clear up any queries. Often you will discover more about your project from a face to face meeting where people tend to be more open about discussing situations. You can always follow up a meeting with written confirmation if an audit trail is required.

4. Be a good listener.

Listening skills are key to being a successful BA. You must be able to listen and absorb information. This will allow you to analyse thoroughly the information gathered to specify requirements. It’s important that you don’t just listen to what’s being said, but are able to understand the context of what’s being said – the motivation behind it, the circumstances behind what’s being said, and even what’s not being said. Voice tone and body language can help you understand the message behind the words.

5. Hone your presentation skills.

It is likely that at some point in your career as a BA you will need to facilitate a workshop, or present a piece of work to a stakeholder or project team. Consider the content of your presentation and make sure it matches the objectives of the meeting – there is no point in presenting information about implementation methods if the meeting is being held to discuss requirements gathering. These presentations are not only for you to present information. They can also work as an excellent way to extract more information or clarity from stakeholders if you are unclear on something or are looking for more detail on a particular area of the project.

6. Be excellent at time management.

A BA must have excellent time management skills to ensure that work is completed on time and the project does not fall behind schedule. Multi-tasking is an important skill, but you must also be able to prioritise activities – understanding which are more critical than others – and concentrate on them. Remember that you need to manage your own time and activities, but you may also need to manage other people’s time if you are dependent on them for information. Make sure that they know when you need them to deliver.

7. Documentation and writing skills.

Requirements documents, reports, specifications, plans and analysis. As a BA you will be required to deliver a range of different types of documents. You will need to ensure that your documents are written in a clear and concise manner, and at a level that is appropriate for your stakeholders. Avoid nuances specific to a particular workstream as they may not be understood by all stakeholders. As an inexperienced/beginner BA, it is unlikely that you will have experience writing requirements documentation, however, strong writing skills are an excellent starting point. Experience will lead to clear and concise requirements documentation.

8. Stakeholder management.

It is essential that you know how to manage all of you stakeholders and know how much power and influence they have on your project. Stakeholders can be your strongest supporters or your biggest critics. An experienced BA will be able to analyse how much management each stakeholder needs and how they should be individually managed. Do they need face to face meetings and detailed information or are they content with high-level reports? Are they supportive of your project? Knowing the answers to these key questions will help you to manage your stakeholders and the wider project. Can you influence them directly or do you need to influence someone who can influence them.

9. Develop your modelling skills.

As the saying goes a picture paints a thousand words. Techniques such as process modelling are effective tools to convey large amounts of information without relying on text. A visual representation allows you to get an overview of the problem or project so that you can see what works well and where the gaps lie. A typical process model will have several different levels of detail to allow a BA to engage with stakeholders in a language that they understand.

Don’t forget to leave your comments below.

BABOK Version 3 vs. Version 2 – Taming the New – Guide Part 1: Knowledge Areas and Tasks

Written by Richard Larson on June 4, 2015. Posted in Articles.

Most people in the BA field know that the IIBA® has produced an important update to its definitive Business Analysis Body of Knowledge, the BABOK® Guide. Released in April 2015, the BABOK® Guide includes major upgrades, ranging from the BA Core Concept Model™ (BACCM), to changes to most Knowledge Areas, the addition of 16 new techniques, and the addition of an all-new section containing five perspectives on Business Analysis.

By IIBA’s estimation, the BABOK has grown 50% from version 2 to version 3 and now has more than 500 pages. It has a richer and more complete set of information about the practice of Business Analysis. It also means the CCBA will have a greater amount of knowledge on which to test aspiring CBAP and CCBA candidates. Both points are good for the profession in our opinion.

Most comparisons of the two versions cover the major changes and ours is no different. However, we begin with the familiar aspects of version 2 and how they change in version 3. Part 1 features changes to Knowledge Areas and Tasks. Part 2 covers the expansion of Techniques, and Part 3 presents the two major BABOK additions: the BACCM and the Perspectives.

BABOK VERSION 3 KNOWLEDGE AREAS AND TASKS

We are starting the BABOK differences with the Knowledge Areas (KAs) and tasks instead of the Core Concept Model for two main reasons. First, most people are familiar with the KAs and their tasks, so it makes the jump to v3 a little less of a leap. Second, the BACCM surrounds the KAs and for each KA the BABOK Guide version 3 shows how the BACCM applies to it. Our view is that v3 is not as big a change as one might think when doing a KA to KA comparison.

Below is a table we compiled to show the differences in tasks. After finishing a draft we then consulted with the BABOK Guide’s table of differences and the result is shown in Table 1.

Some tasks have not changed much or at all, such as “Plan Business Analysis Approach” or “Verify Requirements. “ The task names of some 10-11 tasks have remained the same, which means roughly 21 tasks have been changed, added or deleted. There are now only 30 tasks compared with 32 in v2.

BABOK® Guide Version 2 Knowledge Area and Task Names	BABOK® Guide Version 3 Knowledge Area and Task Names (additions/changes in v3)
2.0 BA Planning and Monitoring – v2.0 tasks	3.0 BA Planning and Monitoring – v3.0 tasks
2.1 Plan Business Analysis Approach (content for prioritization and change management moved to Plan BA Governance) 2.3 Plan Business Analysis Activities	3.1 Plan Business Analysis Approach 3.3 Plan Business Analysis Governance
2.2 Conduct Stakeholder Analysis 2.4 Plan Business Analysis Communication	3.2 Plan Stakeholder Engagement
2.5 Plan Requirements Management Process (see note for Plan BA Approach)	3.4 Plan Business Analysis Information Management
New Task:	3.4 Plan Business Analysis Information Management
2.6 Manage Business Analysis Performance	3.5 Identify Business Analysis Performance Improvements
3.0 Elicitation – v2.0 tasks	4.0 Elicitation and Collaboration – v3.0 tasks
3.1 Prepare for Elicitation	4.1 Prepare for Elicitation
3.2 Conduct Elicitation Activity	4.2 Conduct Elicitation
3.3 Document Elicitation Results 4.4 Prepare Requirements Package 3.5 Communicate Requirements (Note: ours is more complete than the BABOK comparison)	4.4 Communicate Business Analysis Information
3.4 Confirm Elicitation Results	4.3 Confirm Elicitation Results
New Task:	4.5 Manage Stakeholder Collaboration
4.0 Requirements Management and Communication – v2.0 tasks	5.0 Requirements Life Cycle Management – v.3.0 tasks
4.1 Manage Solution Scope and Requirements	5.1 Trace Requirements (Especially relationships) 5.5 Approve Requirements (Conflict and Issue Management; Approval was formerly an element)
4.2 Manage Requirements Traceability	5.1 Trace Requirements (“Configuration Management System” becomes “Traceability Repository”) 5.4 Assess Requirements Changes (Impact Analysis moved here)
4.3 Maintain Requirements for Re-Use	5.2 Maintain Requirements
6.1 Prioritize Requirements (from Requirements Analysis)	5.3 Prioritize Requirements (Moved from Requirements Analysis in v2)
4.4 Prepare Requirements Package 4.5 Communicate Requirements (both become part of “Communicate BA Information” in Elicitation and Collaboration)	4.4 Communicate Business Analysis Information
New Task:	5.5 Approve Requirements
5.0 Enterprise Analysis – v2.0 tasks	6.0 Strategy Analysis – v3.0 tasks
5.1 Define Business Need	6.1 Analyze Current State 6.2 Define Future State
5.2 Assess Capability Gaps	6.1 Analyze Current State 6.2 Define Future State 6.4 Define Change Strategy
5.3 Determine Solution Approach	6.2 Define Future State 6.4 Define Change Strategy 7.5 Define Design Options 7.6 Analyze Potential Value and Recommend Solution (Note: ours is more complete than the BABOK comparison)
5.4 Define Solution Scope 7.4 Define Transition Requirements	6.4 Define Change Strategy
5.5 Define Business Case	6.3 Assess Risks (was an Element in v2 Business Case task) 7.6 Analyze Potential Value and Recommend Solution (Business Case is also now a General Technique)
6.0 Requirements Analysis – v2.0 tasks	7.0 Requirements Analysis and Design Definition – v3.0 tasks
6.1 Prioritize Requirements (Moved to Requirements Life Cycle Management)	5.3 Prioritize Requirements
6.2 Organize Requirements	7.4 Define Requirements Architecture
6.3 Specify and Model Requirements	7.1 Specify and Model Requirements
6.4 Define Assumptions and Constraints	6.2 Define Future State 7.6 Analyze Potential Value and Recommend Solution
6.5 Verify Requirements	7.2 Verify Requirements
6.6 Validate Requirements	7.3 Validate Requirements
New Task:	7.5 Define Design Options (pulls together v2 Determine Solution Approach, Assess Proposed Solution, and Allocate Requirements)
New Task:	7.6 Analyze Potential Value and Recommend Solution (pulls together v2 Define Business Case and Assess Proposed Solution)
7.0 Solution Assessment & Validation – v2.0 tasks	8.0 Solution Evaluation – v3.0 tasks
7.1 Assess Proposed Solution	7.5 Define Design Options 7.6 Analyze Potential Value and Recommend Solution
7.2 Allocate Requirements	7.5 Define Design Options
7.3 Assess Organizational Readiness	6.4 Define Change Strategy
7.4 Define Transition Requirements	6.4 Define Change Strategy (Also see Requirements Classification Schema)
7.5 Validate Solution	8.3 Assess Solution Limitations
7.6 Evaluate Solution Performance	8.5 Recommend Actions to Increase Solution Value
New Task:	8.1 Measure Solution Performance
New Task:	8.2 Analyze Performance Measures
New Task:	8.4 Assess Enterprise Limitations

Table 1: BABOK v2 vs. v3 KA and Task Differences (table modified from BABOK Guide® version 3)

BABOK VERSION 3 KA AND TASK SUMMARY

The changes to BABOK Knowledge Areas and their associated tasks on the surface may seem to be significant. Only one KA name (BA Planning and Monitoring) survives intact from v2 to v3. Only nine task names are the same or roughly the same. This article does not cover details like inputs and outputs, and many of those names have changed from one release to the next.

Upon closer examination, though, the changes are actually not so dramatic. We can summarize a few observations.

Even though most KA and task names have changed, in many cases they are merely refinements rather than significant changes. For example:
- The Elicitation KA in v2 is now Elicitation and Collaboration. Most tasks in that KA are the same with the addition of the “Manage Stakeholder Collaboration” task.
- The v2 “Conduct Stakeholder Analysis” task in Planning and Monitoring has been changed in v3 to “Plan Stakeholder Engagement.”
The Requirements Management and Communication KA and Requirements Life Cycle Management (RLCM) are essentially similar. An important addition is that prioritize Requirements is placed in RLCM.
Enterprise Analysis has become Strategy Analysis, essentially broadening its scope. It now includes devising change strategies, transitions, and organization readiness.
Requirements Analysis is similar in v2 and v3, despite the addition of the concept of “Design.”. An important distinction has been made by IIBA between requirements and design, which boils down to the distinction between business needs and solutions to those needs.
- Requirements – the usable representation of a need (see our forthcoming article on the BA Core Concept Mode).
- Designs – usable representation of a Solution. A new task “Define Design Options” has been added to focus on the BA work in designing solutions. Another new task “Analyze Potential Value and Recommend Solution” actually pulls together facets of two tasks from v2.
Solution Assessment and Validation has been renamed as Solution Evaluation. There are three new tasks as the table shows. They were added to clarify the work of evaluating solution performance over its lifetime including organizational constraints.
Out of the 32 tasks in v2, only eight have been added, a 25% change. That means 10 have been removed since there are now 30 tasks in all.

In short, BABOK version 3 is better organized than its predecessor, and with refined KA and task names contains a structure that better reflects the practice of business analysis.

In the next part of this article, we explore changes to BA techniques in BABOK version 3.

Don’t forget to leave your comments below.

From the Archives – The Value of Business Analysis: Assessing Organizational Readiness

Written by Aaron Whittenberger on June 2, 2015. Posted in Articles.

Originially Published 10/27/14

One of the key roles of Business Analysts in the solution implementation process is to assess the readiness of the organization to take full advantage of the new solution. This is the role in which the Business Analyst acts as a Change Agent in the organization. Whether this is a software enhancement, new system implementation, business architecture, business intelligence, data, business process, product change, or change implemented by a customer, supplier or regulator, effective communication of the upcoming change to all affected by the change is important to preparing the organization to capture the expected benefit of the change.

The Goal

The goal of an organizational readiness assessment is to make sure that all affected parts of the organization, inside and outside the organization, is ready for a change that is about to take place within the organization. Effective communication is the key element in informing the organization that a change is on its way. The communication plan should include a description of the change, why this change is necessary and being made, how it will impact all the parts (business units) of the organization and the necessary steps of organizational change to prepare for the change. When the change is big enough, simple communication may not be enough to prepare the organization for the change, and training requirements need to be identified.

External Initiated Change

Sometimes a change is initiated by an external organization or agency that impacts your organization. This may be a customer, supplier or business partner that makes a change for their organization that impacts yours; such as they change a system interface you use to get information to or from them, or they change a business process that impacts your processes. Sometimes this is a regulatory agency that enacts a new legislation or guideline that your organization must conform to. This mostly impacts organizations in heavily regulated industries such as financial services, pharmacy or biotech.

Internal Change Affecting Others

Your organization may make a change of its systems or operations that affect your customers, suppliers or business partners. Your communication plan must extend beyond the walls of your organization; you must inform your business partner(s) of the upcoming change, timeline and the expected impact upon their organization.

Internal Change Affecting Only Your Organization

Then there is the change that affects only your organization. Whether this is a system change or operational change, effective communication throughout the organization may determine the success or failure of the change. It may not be that the solution or change was bad or inappropriate for the organization, but the acceptance of the change was not successful. This could simply because affected business units were not informed or prepared for the organizational change; or possibly just not prepared in time for the change.

Elements of the Organizational Readiness Assessment

When assessing the readiness of the organization for an upcoming change, you must assess the organization’s culture, operations and impact of the change on the organizational units. Proper assessment of these elements will give a full picture of the state of the organizational preparedness to make the necessary change to use the new solution.

Culture Assessment

Assess the beliefs, attitudes and feelings of the affected people within the organization and their willingness to accept the proposed change. The goal of this assessment is to determine whether the affected people understand the reason for the change, whether they believe that the change will be beneficial to them and the organization, and they understand why the change is required. So, in general, you trying to determine if the people affected by the organizational change want this change to be successful.

Operational Assessment

Assessing the organization’s operations determines whether the organization is able to take advantage of the new capabilities of the change, and evaluate whether the people within the organization are prepared to make use of the new solution. Determine if training is necessary and has been performed, whether new policies or procedures have been defined, whether IT systems are in place to support the new solution are in place, and whether the solution is capable of performing at the required level to give the organization the expected benefit.

Impact Assessment

Impact assessment assesses whether the people within the organization understand how the change will affect them. Some things that need to be examined are the functions, location, tasks and concerns of these people and the impact of the change on these things.

Transition Requirements

From this organizational assessment you may be able to identify transition requirements; capabilities needed to get from the current state to the new solution. Once the new solution is implemented these capabilities are no longer needed. Training is such a capability. Training on a new or enhanced system, new procedures or business process may be necessary, but once everyone affected is trained continual training is not necessary. For a system migration, it may be necessary to migrate data from the old system to the new system. Once the data is transferred, it will not be necessary to perform that function again. You may have manipulated servers or system communication channels to move that data more easily and quickly. Once the data is migrated, you may remove those capabilities.

Implementation Plan

The organizational assessment may identify transitional requirements, and these may become part of the Implementation Plan. The implementation plan is the plan for implementing the new solution, or how we get from current state to the new solution. The implementation plan will identify the culture, operational, systems and stakeholder changes that must be made to make full use of the capabilities of the solution being implemented. This is the essence of the organizational change; the execution of the implementation plan takes the organization from its current state through the changes necessary to prepare for the main organizational change to take place.

Conclusion

Changes within organizations aren’t just made, they are planned then executed. Assessing the state of the organization and the steps the organization must make, on a culture, operational, technical and stakeholder impact level is necessary to ensure that the organization will gain the most benefit from the new change solution. Proper organizational readiness assessment will help ensure that the organization is prepared to implement a new change solution for the organization and take full advantage of the new capabilities of that solution.

Don’t forget to leave your comments below.

Why Are We Still Talking About the Role of the BA and PM on Agile Projects?

Written by Angela Wick on May 12, 2015. Posted in Articles.

It seems like we have been talking about this for 10+ years! We probably will continue the discussion for another 10!

Titles cause confusion. As Kupe’s blog talked about last month, confusion still exists regarding the PM and BA roles in general. The industry works hard to clearly define these roles, but the real-life challenges of organizations make perfect alignment to industry role definitions impossible. And, more recently, agile roles have been added to the mix.

As more and more organizations transition to an agile mindset, new roles get added to the mix, causing even more confusion. When I work with emerging agile teams, common title and role-related questions include:

Do agile projects & teams have BAs?
Do PMs become Scrum Masters?
What is the BA’s role on an agile project?
Is the Scrum Master the same as a PM?
Do BAs become Product Owners?
Is the Product Owner a SME or a sponsor?
Is QA part of the agile team or are they separate?

We really need to stop asking these questions! When organizations all define these titles differently to begin with, how can the industry answer this for everyone? We need to stop trying to draw lines from traditional titles to agile titles. It doesn’t work—there is no direct translation—no 1:1 conversion. We get frustrated because this is the mess going on in our minds:

Real people work on agile teams, not titles. What strikes me when I hear the role confusion questions about agile is: Did we have hiring managers searching for Scrum Masters and Product Owners before? No, these are simply new titles that have been popularized by the common agile team member roles.

These may be newer roles or titles for organizations implementing agile, but that does not mean that they are completely new people. So, where have we been getting the real people for these roles? From PMs, BAs, Tech Leads, Solution Architects, Business Managers and Product Managers—people with experience in traditional roles. Many times, their titles are not changing! So, by formal title I can be a Business Manager and play the role of a Product Owner on an agile team. I can be a BA by title and be part of an agile team, where my role depends on what the team needs and what talents I bring to the team.

The same tasks need to be completed on agile and traditional projects, but the timing, format, and accountability changes as well as the definition of “done.” The agile team determines these aspects by applying agile principles to determine what will add the most value to the process and the customer.

As BAs and PMs we always ask our stakeholders “why is something done” and we dread the common “we have always done it that way” response. We need to ask ourselves the same question about our work. Why do we do what we do? Can it or should it be done at a different time, in a different format, at a different level of detail, as a team instead of as individuals, to get even better results?

If we can let go of titles and focus on skills, techniques, and continuous improvement, we can minimize the confusion involved in the transition to agility. Let’s stop asking where the BA or PM fits into agile and start looking at real people who have a mindset needed to collaborate and successfully deliver value to our organizations!

Our mindset needs to shift to something like this:

The same basic skills are required for every software development effort—it’s how and when you apply them that varies. How can you apply agile principles to your organization to inspire innovation and maximize value?

Review the agile manifesto and the agile principles. Don’t ask where the BA fits or how the PM role changes. Focus on building a team with skills that align with agile principles and question how your approach to work aligns with the principles:

How do we promote consistent and continuous teamwork and collaboration?
Are we constantly focusing on value in everything we do?
Are we focusing on dialog and discovery over process and documentation?
How do we encourage people to let go of job descriptions and empower them to jump in and help as needed with a variety of roles and responsibilities?
Do we have team members with facilitation skills that create a sense of shared understanding and make stakeholders feel safe, knowing prototyping, iterations, and collaboration often can replace reams of paper?
Do we have team members who can elicit, identify and communicate requirements?
How do we manage and adapt to change? Do we have team members who are rigid or flexible?
Who are the people in our organization with strong vision?
Which people in our organization can help groups simplify, prioritize and make progress?
Do our team members have the leadership skills needed to self-organize?

This transition to an agile mindset can be difficult for traditional organizations.

Why? Organizations, especially large ones, are defined by their structure. Titles and processes provide the foundation for accountability (job descriptions, hiring, performance evaluation, termination, etc.). So, the real driver of difference here is that agile commands us to think differently about accountability and structure, and how we deliver value. The agile mindset demands:

Flexibility: With a focus on continuous improvement, the roles and responsibilities of agile team members need to change with the needs of the customer, the team, and the business environment.
Equality: Agile principles limit hierarchy and job descriptions. The team rolls up their sleeves and works together providing whatever skills are needed to bring value to the customer.
Continuous Collaboration: To consistently deliver working software in short timeframes, agile team members need to stay focused. Job titles and responsibilities outside of this focus might need to be restructured if they divide the attention of a team member.
Customer Satisfaction: Customers need to be available to consistently collaborate, preferably face-to-face, with the agile team and to review regular releases of working software/products.

The more we try to place accountability on individuals/roles/titles the less agile we really are. This does not mean there is not a role for BAs and PMs on agile teams. Instead, it means we need to rethink how we define role or title. We need to define them by focus, mindset, and objectives, not by documents and individual accountability. Agile is a transformation, at an organizational level, that challenges teams and organizations to think, act, behave and lead differently.

We also need to understand what tasks and processes should remain outside of the core team. Too many organizations try to fit every project task into an agile framework, which often limits their agility. Supporting and overhead tasks like audit, governance, documentation, training, etc … if needed, can be done by a supporting or partner team. This allows the core team to remain focused on product value and delivery.

What do you think? Are titles getting in the way of your organization’s transition to agile? How do you find the right people/skills for your agile teams? Please leave your comments below.

Don’t forget to leave your comments below.