Removing Barriers To Scaling Agile Adoption: An Introduction

When Agile software development practices are introduced into an organization, they often spread faster than they can be controlled.
Without a clearly defined standard to guide your implementation, numerous Agile management approaches can emerge simultaneously—sometimes in direct conflict with one another. That’s not necessarily a bad thing, but traditional, top-down management structures typically experience some growing pains as they transition to the more egalitarian Agile approach. As an executive, how do you embrace Agile yet mitigate risks in scaling technology, people and processes?

This blog series attempts to answer that question and offer a road map to scale Agile adoption for enterprises embarking on that journey. I’ll present common roadblocks you are likely to encounter along the way.

These impediments, which will be the topics for this blog series, can be classified in four main categories: people; processes; technology; and teams, management, and culture.

Let’s explore the first topic.
Which enterprises will successfully adopt agile?
What types of projects are most suitable for applying Agile practices?

It’s even more important to consider the organizational setting where the work gets done. Any project can succeed in Agile; what dictates if it takes off or stalls out are the organiza­tional and cultural constraints of the enterprise.

Lean Software Developer Tom Poppendieck sums this idea up: “The constraints on when Agile approaches can be used are primarily organizational and cultural, not project types. Some organizations and some contexts are incompatible with Agile/Lean thinking. When these organizations eventually come up against a strong competitive threat, they will fail to meet it unless they change their values and mindsets. Lean/Agile is, at its foundation, the fourth industrial paradigm, the first being Craft Production, Factory Production with machine tooling, Automation, and Taylorism. These come along every hundred years or so and take a few decades to work through. Each paradigm includes the preceding one and makes it dramatically more productive.”*
There is no need to sell Agile except to organizations that want to survive long term. If they don’t see the threat/opportunity, they cannot succeed with Agile or Lean nor can they sustain economic viability in the long run.
The best indication that it will be able to make the transition is a willingness to listen and change accordingly. Many organizations insist that they listen to their employees and foster an Agile culture, but that claim is frequently disproved when Agile values conflict with organizational values. Such a culture clash reveals just how deeply embedded traditional waterfall-ish mentalities are. Frequently, enterprises are unwilling to break from habit, even when short range difficulties will yield long- term improvements.
Consider an organization with a lot of up-front analysis and design. How does its employees respond when asked to write User Stories? Do they insist that Use Cases are better than User Stories? Or do they ask to be shown how to write User Stories? The employees who are open to the new paradigm will transition to Agile faster and with better results. Other issues, though, are more tightly woven into the fabric of the organization. Consider an organization that traditionally provides individual offic­es for its developers. How does management respond to the suggestion of common team rooms? Do they justify the status quo or are they willing to experiment with alternatives? In short, for organizations willing to listen and change, there are no issues that cannot be resolved; it is only a matter of time and effort.
That is not to say that change is not disruptive. On the contrary, change of this order sends shockwaves throughout the entire enterprise. When an organization first introduces Agile practices to a team, the team’s difficulties are limited to the immediate adoption of the practices and how they alter their familiar working methods. But after the team acclimates to these new practices, the challenges shift to a larger, team-wide scope. This is how concerns over Agile tend to develop: by shifting from local, individual problems to over-arching, organizational ones. As Agile practices spread throughout an enterprise, the scope and nature of the problems mirrors that growth. Although these issues cannot be anticipated in any absolute sense, it is possible to classify them as groups and highlight some of the most typical challenges organizations encounter, which can be divided into the following four categories: people; processes; technology; and teams, management, and cultur e.
Next week I will share some thoughts on how to overcome impediments due to overly specialized skill sets, lack of ownership, refusal to work with the team, and mixed signals from management.

The post Removing Barriers To Scaling Agile Adoption: An Introduction appeared first on


7 Habits of Highly Effective Business Analysts

Highly effective BAs, regardless of their skill level or years of experience, consistently hone their craft. Guided by curiosity and passion, great BAs are always on the lookout for growth opportunities—ways to strengthen and sharpen their skills.

This focus on continuous professional improvement goes far beyond attending an annual conference or workshop. Instead, effective BAs develop daily habits that demonstrate leadership and expertise.

So, I’ll borrow Stephen Covey’s popular “seven habits” framework to discuss the recurrent behaviors that support excellence in the business analysis profession.

Although I refer to these as BA habits, they can be applied to most professions. So, whether you are a project manager, a tester, a techie or a trainer, think about how these habits can help you become a leader in your organization.

Habit #1: Effective BAs engage stakeholders.

BAs need information, cooperation and trust from their stakeholders. Skilled BAs get what they need by building strong relationships. They engage stakeholders in a way that inspires engagement, creativity, collaboration and innovation.

How do you know if your stakeholders are engaged? Well, these are common issues on teams with weak stakeholder engagement:

  • Strongly conflicting requirements between stakeholders.
  • Stakeholders are silent; roll their eyes, sigh or multi-task during meetings.
  • Stakeholders do not contribute to the project. They don’t return phone calls, do not reply to emails, do not review project documents, provide resources, etc.
  • Stakeholders show up late for meetings, leave meetings early or skip meetings.
  • Disparate groups do not understand other stakeholder’s needs and benefits from the project.
  • Progress is slow.
  • Discussions loop in circles.
  • Decisions are difficult to obtain.


Do you see any of those things happening consistently in your organization? Effective BAs use their influence to create an environment that looks more like this:

  • Stakeholders have a shared vision and can communicate the vision to their team/s.
  • Stakeholders understand their connection to each other.
  • Stakeholders trust each other and the BA.
  • Stakeholders enthusiastically participate in meetings.
  • Stakeholders make themselves and their resources available to the BA as needed.
  • Questions, discussion and meaningful debates.
  • Proactive, 2-way communication

Habit #2: Effective BAs research new techniques.

Great BAs love discovering new tools that make work efficient, valuable and maybe even fun. Experts estimate there are more than 500+ BA techniques in use today—literally lurking around every corner. Here are a few ways to find them:

  • Read the BABoK! The IIBA’s comprehensive handbook describes 40 of the most common and useful BA techniques. Current IIBA members can get a sneak peak at BABoK 3.0 by participating in the public review process.
  • Attend industry conferences and workshops. Full-day or multi-day training sessions give BAs exposure to a variety of new techniques, trends, and methodologies. Many training companies and universities offer BA training. IIBA and PMI sponsor events across the world.
  • Network. Connect regularly with other BAs. Ask them about new techniques. Find out what works on their projects. Solicit advice when you hit road blocks.
  • Observe others. Find a mentor. Watch your peers. Which techniques do they use regularly? Are they working? Why or why not? How could you make them better?
  • Borrow from other industries and professions. The most obvious example may be the lean processes project teams have borrowed from manufacturing. Are there techniques you could borrow from an elementary school teacher, a farmer, a scientist or an actor? Definitely!

Habit #3: Effective BAs experiment with new techniques.

Now, it’s time to put those new techniques to work! Stagnation and boredom are the enemy of an effective BA. Applying new techniques keeps BAs motivated, engaged and inspired.

Experimentation often invites risk, but there are many ways to contain possible fallout:

  • Start small. Try a new techniques on small, low risk projects. Apply the new technique to a small part of a big project.
  • Break it down. Find a way to break the new technique in pieces. Try one piece on an analysis or elicitation effort to see if it is works. Then get feedback and adjust course if needed.
  • Find your friendlies. Use a new technique with a small, friendly group of co-workers. Encourage them to give you honest feedback.
  • Set expectations. Let stakeholders know why you are trying the new technique.
  • Ponder plan b. Courage to try new things includes the possibility of failure. Think about the worst case scenario. What’s your plan b if the new technique fails?

Habit #4: Effective BAs plan to re-plan.

I run into so many BAs that get stressed out by estimating requirement deliverables. They often ask, “How can I estimate when I don’t have any requirements yet?” My answer: “We plan to re-plan!”

As the project needs and scope evolve, effective BAs revisit their estimates—they reevaluate and adjust as the project moves forward.

Every BA leader and PM I have talked to about this agrees. It’s totally fine to change the estimate and re-plan, just not at the last hour!

So, set expectations and share them.

  • Make sure the PM and other leaders understand that this is your best estimate based on the current state of the project.
  • Help them understand which factors will increase or decrease estimates.
  • Plan resources: What can you do in the early stages of the project to anticipate estimate changes? Who can you pull in if you get behind? What tools can you use to be more efficient? How can you manage busy SMEs to get good requirements?
  • Look at the value and risk of scope items and adjust the plan accordingly to spend more time on high value and high risk items.
  • If your incentives are based on estimation accuracy, then talk to your leader about re-planning and how it fits in the incentive plan.


Effective BAs know that re-planning will be required to protect the project value. They look at the tasks and deliverables like puzzle pieces that need to be flipped, turned, and shuffled until they all come together in their proper place.

Habit #5: Effective BAs use visuals, often.

In most cases, visual communication is more effective than text-heavy documents or verbal descriptions—humans process visual information more quickly and completely. Effective BAs understand the importance and efficiency of visual communication. They always look for new and improved ways to use visuals in their meetings, presentations and documentation.

Skilled visual communicators:

  • Create high-level conceptual visuals, low-level detailed visuals and everything in between.
  • Tailor their visuals to meet the needs of their audience. Does a CEO want to review a 20-page process model? Does a group of SMEs want to focus on the whole organization or just their piece of the pie?
  • Draw spontaneously on white boards when discussions start spinning.
  • Use visuals in virtual meetings too. They use virtual whiteboards, post-it notes, flow charts, etc.
  • Know that visuals do not need to be perfect. You don’t need to be an artist. You don’t need 100% accuracy on day one. A flawed visual is so much better than starting with a blank page.

Habit #6: Effective BAs develop Underlying Competencies.

Obviously, BAs need techniques and tools to complete their practical tasks, but they also rely on underlying competencies. The techniques are like the tools in the tool box, but underlying competencies (UCs) influence how the tools are used and how the techniques are applied. UCs are the artistry, the finesse, or the soft skills.

Effective BAs continuously refine their UCs in many of the same ways they develop techniques: research, training, observation, experimentation, etc.

Effective BAs maintain dozens of UCs, but here are a few of the most important:

  • Critical thinking and Problem Solving
  • Teaching
  • Leadership and Influence
  • Facilitation and Negotiation
  • Personal integrity
  • Organizational Knowledge

Habit #7: Effective BAs consider politics.

Politics exist in every organization.

In project work, politics usually play out during prioritization efforts: which work will get funding, whose projects fit into an implementation, which requirements get cut.

Skilled BAs don’t ignore politics, but they avoid playing. They work around and within them.

How do effective BAs walk this fine political line? How do they understand and manage politics without getting involved? Good questions. Here are a few ideas:

  • Build wide support to eliminate politics as a factor.
  • Always redirect the team back to the project value. Which requirements, timelines, bug fixes, testing strategies, etc. best support the goals of the project and value to the organization?
  • Gather data. In many cases, good data can tell as story that transcends politics and makes the right answer obvious.
  • Lead with empathy. Understand what each stakeholder is seeing, hearing, thinking, feeling. Use these insights to help you influence each stakeholder.
  • Understand the definition of success for each stakeholder.

Which habits make you a highly effective project professional?

8 Key Factors for Cloud Delivery: Eight CIO Recommendations

To thrive in today’s swift-changing and unforgiving marketplace, companies need accessible, agile and adaptable IT.   Flexible service delivery is the answer.   Here’s how to employ it.   In the post-PC era, IT decision makers have a choice to make: Stay with the platform that got them here? Adopt a private or public cloud? Perhaps IT as-a-service or a mix of all the above?


Whatever you decide, a move away from rigid IT infrastructures is a move in the right direction. According to a recent McKinsey & Company survey, more than half of surveyed officers cited the switch to flexible service delivery as a top priority

The reason is simple: Flexible delivery is more adaptable and costs less. It’s a smarter way to distribute IT to users.

We recently confirmed this with a large U.S.-based telecommunications client that needed its technology to scale to tens of millions of subscribers on demand and then let those same subscribers pick and choose online the services most important to them.

Originally, the company considered a traditional infrastructure and then briefly a public cloud. But after completing a holistic analysis, we determined an internal private cloud would be the best option for three reasons: 1) It met the client’s needs (i.e. time-to-market, minimal downtime, continuity and rapid scalability requirements); and 2) It was less expensive over time when compared with the public cloud; and 3) It left open the option for later incorporating a public cloud if desired.

The beta test verified that the model enabled rapid elasticity, continuity and increased uptime. Mission accomplished.

You can achieve the same results. But only after you consider the following eight recommendations we’ve used to transition clients to flexible service delivery:

1.  Determine your biggest pain point.
No one’s going to say “no” to faster time to market, enhanced computing flexibility, improved performance, tighter security and better service at a lower cost. While all of those areas can certainly be addressed through flexible service delivery, the model you choose will largely depend on your top pain point. In other words, you’ll need to honestly answer the following: What keeps you up at night?

2.  Decide which functions to shift.
Next, you’ll need to designate which functions and processes to switch to flexible service delivery. This entails a “core vs. context” analysis, in which you distinguish business activities that provide you with a competitive advantage from those that should be offloaded to external providers. Remember, what was previously considered a core activity is now often viewed a contextual one, including (but not limited to) network management, tech support, performance measurement and financial planning.

3.  Start with a low-risk pilot program.
For established companies, it’s usually best to dip your toes into flexible delivery before diving in headfirst. You can achieve this by developing a pilot program for non-production processes, back-office functions or anything else that has lower performance requirements and less impact on end-users, such as testing and development. In some cases, however, it might make sense to start with customer-facing applications if there’s a pressing need to market new products.

4.  Identify “chatty” applications.
To get the most for your money, you’ll need to determine the consumption levels of your CPU, memory, network and disk storage. In doing so, you’ll be able to identify “chatty” applications that sometimes incur surprising surcharges between the cloud provider and the business. The more you know, the more you save.

5.  Mind those non-IT bottlenecks.
Once IT has been upgraded to the equivalent of a 12-lane highway with the help of flexible delivery, other parts of the organization cannot remain in horse-and-buggy mode. Well, they can. But they’ll become a bottleneck to your business. The challenge is to optimize the entire enterprise so that other areas don’t hold up the software lifecycle. To do this, you’ll need to educate and update your company culture.

6.  Compare service requirements.
Buyer beware: Most public cloud providers offer standard service level agreements that cannot be customized according to client needs. In some cases, general service levels may be sufficient for a development environment. But they often fall short of the demands of a production environment. To find a service level best suited to you, you’ll need to know the difference.

7.  Check security qualifications.
Security is a top-of-mind consideration, particularly for applications and systems that handle personal information. To ensure your data is protected, always certify a provider’s security qualifications. And know that cloud providers typically conduct security audits at a more intensive level than companies hosting internal private clouds.

8.  Demand transparency with a daily dashboard.
To manage variable costs, you’ll want to monitor your capacity and all of its operational parameters — straight down to the lowest server — with a daily dashboard. With this level of transparency, you can make day-to-day decisions about the level of CPU, memory and storage required and use metrics and trends to make decisions about future capacity financial modeling.

Admittedly, the changes required to move to a flexible service delivery can seem overwhelming. But by following the above advice, you’ll put yourself in a better position to find your own success.

For more information, read our white paper on Flexible Service Delivery (pdf), get inspired by our enabler series on The Future of Work or visit Cognizant Business Consulting.

Uncover the key factors to consider before designing a flexible service delivery model. Read on to find out more:

Lift Your Performance Testing in Financial Services and Reduce Risk

So…. you have to improve the system performance, the rules, meet new demands on the call center, move to architecture faster and more automated than the legacy systems….

Performance testing is a great way to take a look at the whole system before you begin even a legacy lift.

I say this because in order to prepare for a robust performance testing program, the whole system should be ‘decomposed‘ and analyzed from the final end point of Delivery of Services all the way back to the input of information at the beginning of the system. This type of ‘backing through the system’ ensures that each workflow, each touchpoint (SOAP-service, MQ, etc.), each system, and process to support a given line of business has been assessed and evaluated.

In this process, many important metrics are discovered: Response times based on normal and peak usage of a given worktype, workflow, call center, or actual system, as well as E2E coherency. This process is effective whether performance testing has ever been done in the organization or not. Often it is limited to only a short throw of a specific system’s performance. With expanding technology, the system designed even 5 years ago can easliy be out of date. So, a full E2E Performance Testing of a given system has merit, especially if upgrading the platform. Such as a new Claims processing platform/application, Loan Application Process, Policy Management system, or even a workflow management system.

So, in a way, Performance Testing is the elephant in the corner, because it reveals system weaknesses and needs, broken processes, antiquated code, antiquated data, rules revisions, risks/dependencies, and of course costs to shore up or replace hardware, monitoring tools, or review of process efficiencies or inefficiencies. All of these items can be confrontive and require capitalization.

With that said, Performance Testing in the best of lights, is mostly preparation, analysis, education, and a great investment into system fluency. The information gained in this process alone, will provide the following benefits: general health check on the system, prioritization of system needs based upon risk and cost, planning for implementation of needed changes to applications, hardware, processes and product output.

So when I hear “let’s bring in Performance Testing at the end, after everything is built”, you might say I have some concerns. Did you do a system analysis, or did you just build another project/product to operate on the same system without assessing the impact on present load and operations, or what impact this product will bring in the next year or two, or five.

What are the plans to begin ongoing monitoring and assessment of system capability to handle the growing needs and market demands?

Just a few thoughts in case a new system lift, upgrade, transformation, or product release is being considered. Consider Performance Testing the same as an Insurance Policy, and the reviews of your portfolio to have sufficient coverage if you have a loss. Without regular checkups, your ‘policy’ could be out of date, ‘out of force’, or non-renewed.

One last thought. Trying to cram it in at the last minute to use remaining budget for the year, is highly risky. In the past few months, I have seen just that in several cases. Performance Testing is not a fix, rather it is a validation of what you have. If what you have at the last minute is insufficient, going to production will be risky and costly.

Sorry for the bad news, but it is better to do these things FIRST to prepare the way for a successful launch.

Bill Fulbright

A posting from my Linked-In Article with the same Title

My favorite NEWBIE Links to Ruby, Rails, Cucumber, Watir

Well without further ado:

My Favorites List (and growing!)

Furiously ADDING Test focus for AGILE, RUBY, Selenium, Cucumber, Watir

Yes, the time has come.  The light bulb is finally on with a full 110w glow.

Things have changed.  Transition to new approaches for development and testing are solidly underway.  I am going to be adding and recommending books, courses, resources, apps, downloads, etc. regarding all the changes happening in Testing, or should happen in Testing to keep up with the tidal wave of exponential growth in new technology.

So, Please return often, as I am updating as fast as I am finding and learning.

Start with my new PAGE for AGILE Testing Links


Bill Fulbright

Videos You Must See: Simon Sinek on Leadership and Free e-Agile courses

Videos YOU need to SEE

Videos YOU need to SEE

A friend of mine, put me on to a few really good video links, which I am now sharing with you!   He has a set of recommended Videos, some of which are here:

My good friend Mike Nelson (click for his technical testing blog) is a guru in automation, Agile, RUP, you name it. He’s the real deal, and has the chops to show it!   If Mikey likes it, I like it!

“People don’t buy what you do, they buy why you do it.   What you do serves as the proof of what you believe.”

The Golden Circle – Simon Sinek; How great leaders inspire action

Leadership, Golden CircleSimon Sinek: Leadership Expert Simon Sinek’s Website – More tips on The Golden Circle. Simon Sinek Leadership Expert:  How Great Leaders Inspire Action

From CollabNET.comlogo-collabnet

Free Agile Training – some of the clearest and easiest to grasp videos on the fundamentals of Agile Testing.

Happy learning! Bill