Skip to main content

Author: Bob McGannon

To Agile or Not to Agile

Written by Bob McGannon on . Posted in Articles.

FEATURESept4thIt’s hot, it’s valid and its promise is without question. Agile project approaches are becoming more popular because of the ability to reduce risk (in some cases), and produce business value more quickly. Far from a magic elixir however, only certain projects and project environments are suitable for Agile methodologies. In fact, the first and primary means of success is to have an appropriate “filter” through which projects are evaluated for their “Agile suitability.” Here is a guide to creating an appropriate filter for determining which projects would benefit from the use of Agile processes. 

  • An eager sponsor

Any project is doomed without appropriate sponsorship. Agile projects however present additional opportunities for peril should a sponsor be disengaged in the process.
Agile methodologies require significant dedication from the end customer community as well as the technical team. Time commitments and prioritization of project activities against operational responsibilities for knowledgeable members of the business community are paramount to Agile processes. Sponsors need to be willing to conduct frequent reviews and evaluations of the evolving product that are an integral part of the Agile approach to project management and Agile product development. Without a sponsor that is eager and able to support and participate in this process, the Agile approach will not yield improved results over any other methodology.

  • An ambitious, knowledgeable and available business representative(s)

The Agile process is purposefully collaborative. Through the nature of the technical development exercise, the development of tools to enable an untested business process, or both, Agile approaches can help an organization bring functionality to fruition quickly and effectively. This quick and effective approach does not come without impacts however. Those impacts fall in the area of the time involved by people who have business experience (and are usually pivotal in the execution of day-to-day operational processes) working extensively with the project’s technical team members.

The primary characteristic that makes Agile methodologies…well…agile…is the methodology is designed to be responsive to immediate and/or evolving needs. Knowledgeable business people need to consistently reassess the product of the project, the business needs at a micro-level, the priority of the functionality needed by the end customer, and are responsible for the business integration of functions into previously developed pieces of work.  The bottom line is that the business value comes about more quickly due to a well coordinated effort between technical team members dedicated to the project tasks, working in concert with business team members who are equally dedicated. As a team, the business and technical project members enable the frequent adjustments and evaluations required to develop a product without the pre-requisite documentation and analysis that is customarily performed in “waterfall” project lifecycles. Business people are key – if they are not available and appropriately dedicated and knowledgeable, the premise of utilizing Agile methods fails to deliver.

  • Minimal time to verify product viability

Agile’s power comes from its ability to produce quickly, adjust consistently to new knowledge and business change, and to accommodate those needed adjustments into the product of the project. Those learnings however only add power to the Agile process when they can be understood, interpreted and absorbed quickly, so they may be incorporated into the project’s product. If the project being considered for Agile methodologies involves a product that will not be used or easily assessed by experienced customer personnel within a short period of time from when it is first developed and put forth for assessment, a base premise for using Agile goes unfulfilled. Agile approaches consistently involve adding pieces of functionality to a solution in short “sprints”; and then testing and integrating that functionality into the cumulative solution.  Long periods of time between installation and evaluation would create many drawbacks and the value-add of Agile techniques are then diminished. As the technical team rapidly moves from function to function, the best results come from adjustments and improvements that can be identified quickly and put into the product before technical and business personnel move on to other areas of the project portfolio. In addition, longer periods of time between functional production and assessment of those functions would add considerable amounts of complicated regression testing – adding time and risk to the Agile approach. Agile works best when products can be thoroughly assessed quickly after functionality is produced.

  • Minimal business exposure if the product produced is broken

Given the appropriate conditions, Agile is extremely effective in the creation of business functionality in a rapid manner. However, as part of this rapid deployment, the Agile team strives to perform the minimal amount of analysis needed to perform any sprint. Given this, it would be high risk to put a piece of functionality into a production environment for rapid integration and analysis if an error in that product would have a substantial impact or would create a “domino effect” of obstacles for the operational business. The nature of Agile, with its tightly integrated knowledge work between technical and business personnel does not present a high risk of creating error-prone products (no more than other methodologies). However, the rapid change with which a product is altered as new functionality is added to Agile products can present business challenges to end users if not appropriately assessed ahead of time.

  • A willingness to consider a very different approach

Agile is highly iterative, progressively adding pieces to a whole solution. The process involves working through plans for the current “sprint” of functionality production, as well as creating high level plans for the next sprint. Beyond that the plans are only loosely outlined, as a means of maximizing the flexibility of solution development. This is a difficult concept to accept for those in the management team that are expecting to see – and direct – a planning process featuring a Gantt chart which shows what is going to be produced via milestones and by task, over the next 6 to 12 months. Flexibility and the ability to invest in a different work and management approach is necessary for project stakeholders when Agile methods are being considered.

  • The “DNA” to deal with a bit of ambiguity

As discussed in the prior item, the Agile planning process is an intense rolling wave approach. As priorities are consistently assessed during the course of the project, pieces of functionality may be created and integrated in a different order than originally envisioned. In fact, some pieces of originally envisioned functionality may not be produced at all in deference to other business items that may be deemed more important since the original functions were outlined. Agile actually embraces this flexibility and responsiveness – those desiring a highly linear methodical set of objectives produced in tune with a pre-conceived schedule need not apply.

Agile is smart, savvy and responsive – but it is not a universally applicable approach to satisfying business and certain stakeholder needs. The most successful incorporations of Agile methods into organizations are done with a good up front filter, which includes assessments of the items discussed here, to maximize the probability of success in producing products with an Agile approach. 

Don’t forget to leave your comments below.

Short on Time? Have MORE Meetings!

Written by Bob McGannon on . Posted in Articles.

OK, before you think we have gone crazy…we recommend more SHORT, FOCUSED meetings. As project managers and business analysts we often find ourselves with pressing deadlines, frantic team members who are juggling many tasks with little time, and senior stakeholders who place increasingly challenging demands upon us. At the same time, we face unchanging statistics showing that communications issues are at the core of project failures. How do you manage these two imposing situations? Have MORE meetings, but make them count, and do them quickly. Let’s examine why we need these frequent, focused meetings, and how to best conduct them.

The type of meetings we are discussing here are usually no more than 15 minutes; on rare occasion they may take half an hour. Often they are run as daily “stand-up” meetings, in conference rooms with the chairs removed or pushed to the side of the room. This is optional, however, for some the “stand up” aspect of these meetings help keep the attendees focused. These quick meetings are usually first thing in the morning to prepare for the upcoming day, or they are the final thing done at the end of the day, to prepare for activities that will take place early the next business day. So, given this, why are more frequent meetings a useful tool?

1. Your team needs as much efficient heads down time as is possible

Rarely do any projects allow team members to operate in a vacuum. Conditions change, problems and unexpected circumstances surface. Communication from the project’s various stakeholders is virtually constant. Team members need to a) know what their mission is on the project and b) have the information they need to get their tasks accomplished in the best way possible. With this constant flow of needed data, the forum to communicate all of this information requires frequency and efficiency. The short, focused, and regularly scheduled meeting can accomplish this. The project manager can also receive information from team members relative to status, risk management and issue information in an efficient fashion as well.

2. Team members need to know about dependent tasks, and required interactions

In our formal project management training, we spend considerable time (appropriately) on risk management. Classical risk management talks about potential events that may affect the project, the completion of project tasks, or the project mission as a whole. In the fast paced, increasingly technical area of product development, it is just as important that we treat information about dependent tasks and other potential interactions with other team members, major stakeholders or vendors, like we do for risks. We need to recognize these interactions, plan what we need to do to address them, and be prepared if the interaction event takes place. These interaction events can cause us to have to review data, review status, alter our approach, or in the most significant instances, re-plan how we are accomplishing our tasks. Only through interaction with our peers and leaders, and obtaining timely information from stakeholders can this be accomplished efficiently and effectively. We don’t need extensive ‘interaction management plans” to do this; however we do need to interact frequently about the potential, so we can be prepared for upcoming project situations.

So, given these meetings are so important, how do we make them effective in both maximizing team members’ “heads down time” and preparing them for these potential “interaction events?”

1. Don’t make them mandatory – make them “conditional” and you control and communicate the attendance conditions.

The legitimate complaint that most people have about meetings is that they are a waste of time. They go too long, and they aren’t useful. We get into the habit of inviting the “standard team set” to every meeting. When your team is crazy-busy, we need to step to the plate as leaders and make the effort to determine WHO needs to be at our short, focused meetings. So, set the conditions for your team members as to who should attend, communicate those expectations, and share the conditions before every meeting so those that don’t need to be there won’t need to attend. When you first start this technique, fail on the side of conservatism and have people attend. As time progresses, and you get feedback on the usefulness of the meeting, you can fine tune your attendance condition setting. The key to this is simple…if YOU can’t identify the critical piece of information they will take away from the meeting, then they do not need to be there. If YOU need a piece of information from a team member – collect that at the very start of the meeting. Carl Pritchard’s “Wall Walk Protocol” is a great approach to doing this for larger project teams.

2. Hold more than one daily meeting – with different attendees

This might not be as efficient for you as the project manager or the lead business analyst, but this isn’t about you. It is about the productivity, effectiveness and efficiency of the team. If you do this well, and your team feels you are conducting effective meetings that are worthwhile and they get the information they need, you will benefit from a) not having to chase people down to get or share information and b) they will work with better data, which will reduce the issues that you will have to deal with. This usually saves you more time than you will spend on setting attendance conditions and holding separate meetings. Holding separate meetings – and doing this well – avoids the biggest time waster in meetings…that of having to listen to someone drone on about something that isn’t meaningful to them. Divide your team into sub-teams of people that work together often, and have separate daily meetings. To maintain “a whole team” consider having the entire team attend one of the daily meetings each week. Set the agenda for that team meeting be things of relevance to the entire team.

3. Take the meetings seriously, but don’t force yourself and your team to be serious

Efficiency not only comes from getting and giving information effectively and in a manner that is valued by team members. Efficiency also comes from team members that know and understand each other in more than a professional capacity. Take time to recognize birthdays, significant accomplishments, not so significant accomplishments, and times when you acted as a team. Bring cookies or breakfast to the weekly whole team meeting – be human yourself as the leader and encourage your team members to do the same.

4. Talk about the “elephant in the room”.

Because the group of people will be small, take advantage of the intimate size. Cut to the chase and bring up topics that might be “taboo” in a larger group situation. The more open and forthright about providing information you are, the more the team will feel comfortable doing the same. Information is key to our success and the earlier people open up to share “bits of vital information” the better positioned the project will be for success.

Don’t forget to leave comments below.

Dealing with the ‘How’ When You are Looking for the ‘What’

Written by Bob McGannon on . Posted in Articles.

BA_Mar_20_How_2977510_XSIt is the classic problem facing business analysts and other project team members who are collecting project requirements – when asking “what needs to be done?” the responses from stakeholders invariably describe ‘the how’. Many requirements collectors overlook the value of this input, as it can be used as a springboard to more complete, valid project requirements. Here is how you can take this ‘how’ input and extract the most value from it as you create your requirements documentation.

Collect and Separate

Rather than reject the input that describes how to accomplish something, versus getting details on what needs to be accomplished, capture the input as valid and characterize it. As you listen to your stakeholder and record their input, use a flipchart with two columns:  one marked ‘What’ and the other marked ‘How’. Recording instances where the stakeholder has shared ‘the how’ allows you to recognize their input as valid, and pursue the requirement further with questions such as “What would you do with this tool if it was available to you today?” Through this questioning, you can ascertain ‘the what’ behind ‘the how’. According to Mindavation staff member and business analysis expert Haydn Thomas, “Sometimes ‘the how’ reflects the essence of the way your stakeholder understands their requirement. Capturing it, and asking further details, not only validates the stakeholder’s need, but it gives you additional understanding as well.”

 Utilizing this technique also serves to reframe the thinking of your stakeholders, which can yield additional requirements. As the stakeholders see the project team member sorting the requirements into the ‘what’ and ‘how’ it is likely the stakeholders thinking will mirror this approach. Lastly, when repeated, the ‘what’ and ‘how’ separation technique will help instill better habits amongst stakeholders as they will see the focus on obtaining and understanding the ‘what’, and will display a greater tendency to present requirements with a focus on what they are trying to accomplish.

What is missing?

Projects by definition create change in an organization. From the stakeholder’s viewpoint this change could a) fulfill a gap, b) add capability and/or c) increase their productivity or accuracy with the work they perform. If this is true, then something is missing in the existing processes and systems that could enhance their job. A good requirements gatherer will utilize a sense of curiosity to find out what that missing capability is, and what will be required to provide that capability. In addition, characteristics of the missing capability can be explored with the stakeholder to ensure the requirement is fulfilled in a pragmatic, easily acceptable manner. This can be done while still focusing on the ‘what’ – and separating the ‘how’ – should it surface.  In instances where an existing system or process is being altered, stating ‘the how’ can be the best way to understand and capture the requirement into a ‘what’ format. This alteration usually reflects the need of the stakeholder, and describes how a new capability can be incorporated into a current environment without requiring substantial new tools or processes. 

What’s Good About It?

Often stakeholders will share ‘the how’ by actually asking for a process or tool with which they are familiar. This is human nature at work; often stakeholders view this as ‘the what’ when they are actually conveying ‘the how’. They do this because they know of no other example or means of conveying their requirement. If a tool is not mentioned by name, ask for specifics so the tool can be investigated. From there, move on to probing questions about what the stakeholder liked about the tool or process, what they didn’t like about it, and how it changed (or enhanced) the way they completed their work. From this, the requirements gatherer can extract ‘the what’ that is needed to complete project requirements documentation.

Take the Deep Dive

The process of requirements gathering starts with a collection of organizational needs. Ultimately however, detailed requirements including functional requirements, process steps, business rules and performance criteria need to be captured and documented. Although many business analysts are not accustomed to ‘flip flopping’ between high level and detailed requirements gathering, this approach can be effective. With stakeholders that have a definitive ‘how’ in mind, a discussion involving detailed requirements is another way of extracting the ‘what’. This approach can also develop an understanding of the way in which the stakeholder prefers (or needs) to work.

Questions that recognize the tool and process the stakeholder is promoting, yet lead to viable detailed requirements gathering include:

  • When would you use the tool or function?
  • Are there instances when the tool or process you are using had to be augmented by a manual process? If so, when and what was the manual process?
  • In a perfect scenario, how would the tool work?
  • What degree of authority do you have when you use the tool? Could that degree of authority be varied? In what instances would your authority change?
  • What decisions do you make yourself, what decisions are made by the tool or process, and should the decision making approach vary? If so, how?
  • What are the exceptions to the process that require approvals or variances to the normal process?

Check the Viability of the Tool or Process

Many inexperienced business analysts either a) accept the ‘how’ as the requirement or b) ignore the information and fail to recognize the value in the ‘how’ input they receive. It is important to keep in mind that, in the mind’s eye of the stakeholder, the ‘tool’ they are proposing is their understanding of a requirement. Proper, balanced and open minded investigation on the part of the analyst is appropriate to understand the stakeholder’s requirement. A great deal can be learned from this investigation, including:

  • Verifying if there is a tool or similar process that is already available within the organization
  • Discovering functionality that might be beneficial with other stakeholders or on other projects
  • Developing a greater understanding of the process(es) the stakeholder is expecting to utilize
  • Understanding if cross functional relationships between processes or tools exist that might increase organizational efficiency

Care should be taken when investigating these tools or processes however. Common items that should be noted and probably avoided when moving to the solution stage of the project lifecycle are:

  • Stakeholder enthusiasm due to familiarity with a tool. Other tools might be as good or better and not known to the stakeholder
  • Influence from marketing. Effective marketing of a product, tool or service can make it appear there are few or no other choices in the marketplace. Careful scrutiny of these stakeholder requests should be applied
  • Holding on to the current state. Many ‘requirements’ come from an unexpressed desire to minimize change in the stakeholders approach to work. This is not always prudent.

Requirements gathering is a fine art. Successful requirements gathering is best performed by taking full advantage of all the input received from stakeholders. Sorting the ‘how’ from the ‘what’ and investigating appropriately is an important means of validating the expressed requirements, yet staying true to the business analysis objectives.

Don’t forget to leave your comments below.

Bob McGannon is a Founder and Principal of MINDAVATION; a company providing program and project management training and consulting, leadership workshops, keynotes and project coaching worldwide.