Tag: Requirements

A Project Manager’s Guide to Requirements Modeling

Written by Elizabeth Larson on March 17, 2015. Posted in Articles. 5 Comments on A Project Manager’s Guide to Requirements Modeling

We often get asked how project managers (PMs) justify allowing enough time to model requirements on their projects. These PMs complain that although they agree that requirements modeling has huge benefits, they have a hard time justifying the amount of time it takes. This article opens a series on requirements modeling with the emphasis on why PMs should care about modeling requirements. Each article looks at a single model, the benefits of that model to the project, the questions PMs need to ask related to that model, and how much the PM needs to understand in order to manage the requirements modeling activities.

What is a model? A model is a representation of reality, like a model car, airplane prototype, or graphical design (e.g., a CAD drawing) of a house. As they relate to requirements, models usually consist of text, graphical representations, or both. Most models have both diagrams and textual components. Text can be sentences (user stories), tables, matrixes, or lists, but words are the primary component. Diagrams (process models and use case diagrams to name a few) are usually visual methods of representing requirements. In software development there are several complementary models that help elicit requirements.

Models can be developed using a variety of techniques, including facilitated workshops, one-on-ones, prototyping, and others. An advantage of graphical models is that they can reduce the ambiguity when only text is used. We will review a number of different models in subsequent articles. Each modeling technique helps ask the clarifying questions needed to uncover hidden requirements. These techniques are interdependent and each is usually completed iteratively throughout the completion of requirements activities.

Why Model Requirements? In this series, we explore the relationship between requirements elicitation and requirements modeling, elicitation being about asking the right questions. We know that for our projects to succeed and for us to get the information we need to build our end-product, we need good requirements. To get good requirements, we need to ask the right questions. We need to ask both high-level consultative questions to determine the true business need, as well as questions about the features, characteristics, and functionality needed for the end product. We need to go beyond the “who, what when, where, and why” questions which, although helpful to start us out, rarely get to the detail we need. We’ll explore how modeling helps uncover requirements related to these product features and functions in each of the articles in this series.

In addition, there is risk associated with not getting good requirements. Reports like PMI’s 2014 Pulse of the Profession¹ points to the need for getting our requirements right and the high costs associated with not doing so. The Standish Group’s Chaos reports consistently point out the need for stakeholder involvement to get good requirements.²

Iterative elicitation and modeling. We can’t start out modeling requirements without some understanding of the end-product. Therefore, we need to ask enough questions to be able to develop an initial model of the requirements. Once we have a picture, or model, we can start to see the gaps in the requirements, gaps that will almost assuredly lead to additional questions. We call this process of asking questions and modeling requirements Iterative Elicitation and Modeling. Below is a figure illustrating this relationship between elicitation and modeling. It shows that modeling helps us to ask the right questions, questions we most likely wouldn’t think to ask. Asking questions, then, enables us to model the requirements. Modeling requirements, in turn, allows us to ask further questions and ultimately deliver the product that our stakeholders are expecting.

Figure 1 Iterative Elicitation and Modeling

What does this mean for project managers? Some project managers are directly involved in these requirements activities, and some are not. In either case, we have found that it is not uncommon for project managers to underestimate the complexity of business analysis work including elicitation and modeling. We think it important for project managers to understand the risk of not taking the time to use models to elicit requirements. Regardless of the role doing the work (project manager, business analyst, designer, developer, or whomever), and regardless of the project approach (Waterfall or Agile), the work needs to get done. It might get done by the development team during each iteration on an Agile project, or it might get done during the business analysis phase(s) or a more traditional project, but details of the end product are necessary in order to provide a product that will work for the stakeholders and be one that they want to use. In all cases, this work takes time and needs to be accounted for as the project manager plans the project.

So how do PMs justify taking time to model requirements? First, it is essential for project managers to recognize the importance of asking the right questions during elicitation. Next, PMs need to understand that if they don’t model the requirements, they will probably not be able to ask the right questions. Then PMs need to put time into their plans for these iterative elicitation and modeling activities. Finally, they need to articulate the importance of taking the time to do this work and the risk of not doing so when they think they don’t have the time.

Don’t forget to leave your comments below.

[1] PMI’s Pulse of the Profession In-Depth Report on Requirements Management http://www.pmi.org/~/media/PDF/Knowledge%20Center/PMI-Pulse-Requirements-Management-In-Depth-Report.ashx
[2]The Standish Group, http://www.standishgroup.com/sample_research

About the Authors:

Elizabeth Larson, PMP, CBAP, CSM, PMI-PBA is Co-Principal and CEO of Watermark Learning and has over 30 years of experience in project management and business analysis. Elizabeth’s speaking history includes repeat presentations for national and international conferences on five continents.

Elizabeth has co-authored three books: The Practitioner’s Guide to Requirements Management, CBAP Certification Study Guide, and The Influencing Formula. She has also co-authored chapters published in four separate books.

Elizabeth was a lead author on the PMBOK® Guide – Fourth and Fifth Editions, PMI’s Business Analysis for Practitioners – A Practice Guide, and the BABOK® Guide 2.0, as well as an expert reviewer on BABBOK® Guide 3.0.

Richard Larson, PMP, CBAP, PMI-PBA, President and Founder of Watermark Learning, is a successful entrepreneur with over 30 years of experience in business analysis, project management, training, and consulting. He has presented workshops and seminars on business analysis and project management topics to over 10,000 participants on five different continents.

Rich is a frequent speaker at Business Analysis and Project Management national conferences and IIBA® and PMI® chapters around the world. He has contributed to the BA Body of Knowledge version 2.0 and 3.0, the PMI BA Practice Guide, and the PM Body of Knowledge, 4th edition. He and his wife Elizabeth Larson have co-authored three books, The Influencing Formula, CBAP Certification Study Guide, and Practitioners’ Guide to Requirements Management.

5 Ways to Find Missing Requirements

Written by Laura Brandenburg on March 3, 2015. Posted in Articles. 8 Comments on 5 Ways to Find Missing Requirements

Brandenburg Mar4

Doesn’t it seem like we can hardly go a day without reading about how missed requirements are leading to incredible amounts of wasted time, energy, and money on information technology projects? I have been inside enough projects to know that the statistics are most likely telling a realistic story about how projects get scoped, defined, and delivered, but that they are not necessarily giving a comprehensive account of the situation.

In this article, we’ll look at 5 practices we employ as business analysts to discover hidden requirements, and how organizational pressures, project circumstances, and business analysis processes can negatively impact the outcomes of those techniques, leading to the costly reality of overlooking requirements.

Practice #1 – Requirements Reviews and Buy-In

It is not uncommon to discover dozens of requirements during the final requirements review stage. Walking through a requirements specification, or a portion of a requirements specification, with the goal of being sure everything necessary has been included, almost necessarily uncovers additional information.

When you are getting ready to approve, finalize, or simply be done with a requirement, your stakeholders tend to invest a little extra time and energy in being sure it is right.

But the review process only works if you establish the importance of the review, making it very clear that once we review this document, development will begin based on what is inside it, and that means the cost of change starts to go up.

This stage of the process can go wrong if stakeholders do not show up to requirements meetings, do not understand the enormity of what approval means, or do not feel bought into the project in the first place. It also does not work if a critical stakeholder is not invited in the first place, which leads us to the next way to find missing requirements.

Practice #2 – Include All Possible Stakeholders

While it is never a great idea to invite dozens of people to a single requirements meeting, good business analysts ensure that all relevant stakeholders are looped into the project and given the opportunity to share their concerns, needs, and expectations. If you are consistently neglecting requirements in a particular area, identify a new stakeholder from that area to include on your project teams.

This part of the process can go wrong when business analysts are assigned to specific areas of the business and projects are assumed to only impact that area. It can also go wrong when managers assign uninformed stakeholders to projects or refuse to assign stakeholders at all. Organizational politics can also be a factor, say, if a business sponsor purposely excludes one or more stakeholders from the project.

Practice #3 – Apply Analysis Techniques

While stakeholders are the source of many requirements, other requirements are discovered by analyzing the stakeholder needs and discovering implications. The result of good business analysis is a complete view of the solution. For example, every field on a report must be entered into the system at some point, whether directly by a user or by some sort of data feed.

Unfortunately, well-intentioned templates can negatively impact the analysis process. When you are capturing requirements in long lists, it is difficult to make all of the necessary links between requirements. As luck would have it, the same is true if you are capturing requirements in a substantial product backlog. You need analysis models, such as business processes, use cases, or data models, to help you discover the missing connections.

What’s more, a large template can give the false sense of security. Just because you have filled out a 30 page template with twice as many sections does not necessarily mean that you have discovered all of the requirements!

Practice #4 – Invest (Just) Enough Time

Good requirements take time from stakeholders, from technical experts, and from someone performing business analysis activities. Part of being a business analyst is putting together a reasonable plan that explains the steps you will go through to elicit, analyze, and confirm the requirements, identify who needs to be involved in each step, and about how long each step will take.

While it might seem counter-intuitive, more time is not always better. Business and technology contexts change quickly. Investing too much time in the requirements process can mean that your early requirements become stale before they are even ready to be implemented. Minimizing missed requirements comes from crafting a plan that secures just enough time to discover the best possible requirements given the project goals and constraints.

However, it is not uncommon for a business analyst to be assigned a mere week or two to finish requirements before development on a sizable project is targeted to start. When organizations shrink project timelines, or the time dedicated to the requirements aspect of the project, without also shrinking the scope of the business analysis effort, then we nearly guarantee we will miss requirements.

Practice #5 – Start at the Beginning

You cannot solve a problem that you do not understand. You cannot address a business need that has not been defined. You cannot sell a product that the customer does not want.

Business analysts understand the big picture of the project, which includes why the organization is investing in the project and the over-arching goal to be accomplished.

I would venture to say that the vast majority of missing requirements are actually missed at the very beginning of the project. If no one inside the project compels the business community to be clear about exactly what problem needs to be solved, or if a business sponsor resists a business analyst’s typical “why” line of questioning, the entire team is working like a ship without a rudder. You run the risk of chasing rabbits down holes and discovering a lot of requirements that are irrelevant, while overlooking the big important requirements that should be staring you right in the face.

Create More Positive Outcomes

As business analysts, we can expect to face circumstances that, if left unchecked, will cause us to miss requirements. It is up to us to clarify the conditions under which we can do our best work and improve our contexts so we can improve our requirements.

Don’t forget to leave your comments below.

Requirements without Users

Written by George Pitagorsky on August 12, 2014. Posted in Articles. 2 Comments on Requirements without Users

Conventional wisdom and best practices tell us that end users and other stakeholders must be involved in IT application and other product requirements definition. In traditional mode, the involvement is before design and development. With an Agile approach the users must be an integral part of the project team.

What Do You Do When Users are Not Available?

But, what do you do if users are not available because they are fully engaged in their operational duties and can’t spare the time, are resistant to change, or just not interested enough?

You can wait for them to get on board the development train. That might take a long while and delay a project that can provide significant benefits to the organization.

You can force them to get on. That might get you started, but, as soon as they can or must they’ll jump off and your project will be delayed. Sometimes they will even derail the train.

What if you just start without them? Radical and risky you might say, though it might be the best way to get moving and deliver a useful product in the shortest amount of time. Think of a requirements-without-users approach that is like prototyping. A prototype can be developed based on minimal requirements and then refined until the product is ready for production use.

This approach requires that the following conditions are met, 1) you have a window of opportunity to make use of development staff that might not be available later, 2) your users and sponsors are open to getting engaged later in the process (ultimately they must get involved) 3) your sponsors and senior user management are realistic enough to accept that there will be a lengthy acceptance testing and refinement process that requires involvement by users and stakeholders. once the initial version of the product is delivered and 4) you have alternate means for determining the requirements.

Condition 1: Resource availability

Condition one means that there are programmers and analysts who are waiting for something to do and who have the capacity and knowledge to do the job. In another month, some other project will be ready to start and the resources will be grabbed up. If you don’t get started now, you may never get started.

Condition 2: Buy in

Condition two says that you must ultimately get buy in from users and their management. Buy in to the process of letting the development team has to be earned. It requires that the sponsors trust the development group to work in a way that best supports the needs of the business and that the sponsors are eager to get the project moving. It requires that the user group or groups agree to letting others “read their mind” and postpone their involvement until a prototype is delivered. Buy in to the product will come because business requirements, including efficient and effective operational procedures, are met. In other words, the product must deliver expected benefits and do so in a way that makes good business sense.

Condition 3: Realism

Condition three is realism – a management team that is able to accept a lengthy post delivery change process and who will make make the users and other relevant stakeholders available for the acceptance process. This condition implies that whatever the result of the initial round of development there will be a process to make the result acceptable to its users. It is more than likely, perhaps inevitable, that no matter how product requirements are defined and no matter who defines them, there will be changes that are discovered once the product is delivered. This is the underlying reason for acceptance testing and ongoing enhancement process planning. Taking a requirements-without-users approach generally means that there will probably be more changes than if the users were integrally involved in the requirements definition and in the development itself (as in an agile team). Consider the initial deliverable as a prototype. The acceptance process refines the prototype. The duration of this process depends on the number and type of the changes required and the availability of resources, including the users who will test the product and make requests for change.

In effect, the Requirements-without-Users approach is really a change in the placement of user involvement in requirements definition in the development cycle. in addition to change where in the cycle users are involved, it also changes the nature of the elicitation process. Users must still accept the product and that means they have to make their requirements known. Elicitation is usually done by asking the stakeholders what they want. In this approach stakeholders are asked to verify that their requirements are met by the delivered product.

Condition 4: Alternate Source of Requirements

Condition four is also about realism. In keeping with the reality that nothing spontaneously arises without causes and conditions, requirements have to come from someplace. Where do they come from when the users don’t provide them? There are a number of sources: research into products such as commercial packages for a similar application, the existing application and/or business process and its strengths and weaknesses, change requests and complaints about the existing application and process, research into the needs of the recipients of the output and services provided by the current system, the knowledge of technical staff and business analysts who have been working with the user community for years, and from expert consultants with deep knowledge in the application area.

In most application development projects an existing system is to be replaced. The system, whether automated or entirely manual, has in it many of the requirements for the new system. In effect the new system’s requirements can be inferred from the combination of the existing system’s features and functions and any complaints, change requests and/or project justifications that may be available. Manual procedures can be assessed by shadowing the users or researching standard operating procedures, if they exist.

Every system has people or other systems that provide and receive data or services from the target system. It is possible to infer the requirements of the target system from the needs of related systems. For example, if an application is supporting a service to customers, the definition of the service itself, chronic complaints and problems and knowledge of the existing system’s features and functions, new features and functions may be used to identify the requirements that will enable improved customer service.

Often IT staff and business analysts have significant knowledge of the business areas they serve. Sometimes they are more knowledgeable than the users themselves. In addition, they are structured in their thinking. They can be excellent sources of requirements, though their perspective may be too computer centric to be relied on as a sole source of requirements.

Conclusion

While it is necessary to engage the users of an application in the acceptance of their system, it may not be necessary to engage them in an intensive up front requirements analysis process. The need to take a Requirements-without-users approach to application development arises when users are not available or when they are resistant to change. When the right conditions are met, requirements can be derived from existing systems, the needs of the ultimate recipients of data and services, from knowledgeable IT and BA staff and/or from expert consultants. Based on these requirements a prototype can be created and used to validate that the product meets the users’ needs.

Don’t forget to leave your comments below.

A Fresh Look at Requirements and Requirements Elicitation in Complex Projects

Written by Robert Wysocki on July 28, 2014. Posted in Articles. 3 Comments on A Fresh Look at Requirements and Requirements Elicitation in Complex Projects

Wysocki July28 It is widely accepted that the elicitation of complete requirements during project ideation is very unlikely except in the simplest of projects. There are a number of internal and external factors that affect the solution and its clarity that often change during the project life span that accounts for this. The environment is dynamic. It doesn’t stand still just because you are managing a project! These factors create process challenges that can be mitigated by a simple change in the definition we use for a requirement. This simple change of definition simplifies many of the project management process problems and improves the likelihood of delivering the expected business value.

THE REALITIES OF THE COMPLEX PROJECT LANDSCAPE

As part of the Ideation Phase of a complex project we can define
“WHAT” an acceptable solution has to contain and the business
value it is expected to generate.

At the start of a complex project we may “NOT KNOW HOW” to
achieve an acceptable solution.

The resulting incompleteness is a logical consequence of the
Plan-driven definition of a requirement. That incompleteness can
be removed by using a Change-driven definition of a requirement.

Using a Change-driven definition of requirements implies that an
iterative project management approach will be required.

Most project management processes use a Plan-driven definition of requirements. That will not work in the contemporary complex project landscape. This article introduces a Change-driven definition of requirements. That simple change eliminates the obstacle.

A SOLUTION TO INCOMPLETE REQUIREMENTS

To a certain extent we have become trapped by our own view of requirements and their elicitation. The IIBA definition may fulfill its objectives but at what price? The IIBA definition of requirement is a Plan-driven definition and it tries to define both the “what” and the “how”. In independent projects that works. But in complex projects that seldom works. The Effective Complex Project Management (ECPM) definition of requirements proposed below is a Change-driven definition. It focuses only on the “what”. The “how” is developed within the Work Breakdown Structure (WBS) and the project execution phase.

THE ECPM DEFINITION OF REQUIREMENTS

The IIBA definition is all well and good and I’m not going to challenge it. I assume it accomplishes what its creators envisioned. But let me offer a different perspective for your consideration. I believe we execute projects to solve critical problems or exploit untapped business opportunities with the ultimate goal of generating business value.

The need to deliver business value

Using cost, time and scope as the variables for measuring project success misses the point of doing a project. The success of a project is measured by the achievement of business value – the more the better. The total cost of the project is measured against the business value generated to calculate Return on Investment (ROI) and compare against other projects competing for the same resource pool.

Complexity and uncertainty

The IIBA definition of requirements is a one step Plan-driven definition. That gives rise to incomplete requirements except in the simplest of situations. The definition of an ECPM requirement given below is a two step Change-Driven definition. In the first step the requirements definition focuses on the “what”. At this level requirements are complete. Think of them as defining an ideal end state. With requirement defined the focus of the solution turns to the second step – the “how”.

DEFINITION: ECPM Requirement

An ECPM requirement defines a component of the desired
end state and when integrated into the solution meets one
or more business needs and delivers specific, measurable
and incremental business value to the client business unit.

The set of ECPM requirements forms the necessary and
sufficient set needed to establish the desired end state and
attain the planned business value.

Adapted from: Wysocki, Robert K, (September, 2014), “Effective Complex
Project Management: An Adaptive Agile Framework for
Delivering Business Value”, J. Ross Publishers

“How” is usually not known at the outset of the complex project. It can only be discovered through successive learning and discovery iterations that build upon a solution that is converging to the desired end state. So at the start of the complex project the definition of “how” is incomplete. Very little of the solution might be known at the outset or most of the solution known with only a few details missing but the solution is not completely known at the outset. So the “how” is the second step of the ECPM requirements definition and its discovery is imbedded in the Work Breakdown Structure (WBS).

The necessary and sufficient conditions statement means that all requirements are needed in order to achieve the planned business value and none of the requirements are superfluous. This is important because the project was justified based on the expected business value as described through the success criteria in the Project Overview Statement (POS). Linking requirements to the success criteria provides a basis on which to prioritize requirements.

This definition of a requirement is quite different than the IIBA definition but in its simplicity and uniqueness it puts the connection between requirements and the business value in a much more intuitive light. I have no particular issue with the IIBA definition but I believe that a working definition linked to business value is a better choice. I will use the ECPM definition throughout this article.

An example of an ECPM Requirement
from a project to establish a
Workforce and Business Development Center

A Business Incubation Center (BIC) (Figure 1) to support the needs of students, workers, entrepreneurs and local businesses for career and professional development and business growth.

Figure 1: The Business Incubation Center (BIC)

Requirements will be the causal factors that drive the attainment of the success criteria as stated in the POS. Every requirement must be directly related to one or more project success criteria stated in the POS. This definition results in a small number (less than 12 for example) of high level requirements at the beginning of the project, whereas the IIBA definition generates hundreds and even thousands of requirements which can never be considered complete at the beginning of the project. The last time I applied the IIBA definition resulted in my client and team generating over 1400 requirements! The human mind cannot possibly absorb and understand that many requirements. To expect that a decision as to completeness can be made in that example is highly unlikely. Subject to the learning and discovery that may uncover other requirements, the list generated using the ECPM Requirements definition can be considered complete at the beginning of the project. An ECPM Requirement is a more business-value-oriented definition than the IIBA definition. The learning and discovery derived from completed project cycles will clarify the requirements through decomposing them to the function, sub-function, process, activity, and feature levels. The first-level decomposition of a requirement is to the functional level and can be considered equivalent to IIBA requirements but in ECPM parlance it is no longer a requirement. It is a function that must be present as a condition of achieving the requirement. So while you can identify all requirements at the beginning of the project you cannot describe the details of the requirements at the functional, process, activity and feature levels. This detail is learned and discovered in the context of the cycles that make up the project.

BENEFITS FROM USING ECPM REQUIREMENTS

Framed in the language of the client
Relate directly to the generation of business value
Helps create and maintain client ownership and meaningful involvement
Integrates all of the steps that define effective complex project management
Reduces the number of requirements from hundreds to less than 12.
Become the basis for solution development
Related directly to project success criteria

PUTTING IT ALL TOGETHER

Current definitions of requirements include both the “what” and the “how.” This leads to incomplete requirements specification for every project except the simplest. The result is confusion and problems associated with the execution of the chosen complex project management process. The ECPM Requirements definition focuses on the “what” and with few exceptions will be complete. Choosing the best fit complex project management process becomes a well-defined decision. The “how” is identified incrementally through a Work Breakdown Structure (WBS) derived from the set of requirements.

Deploying this ECPM Requirements definition across the project life span introduces changes to the project management process that have every reason to significantly improve project performance and reduce the risk of project failure. The discussion of those changes is beyond the scope of this article.

Don’t forget to leave your comments below.

What Problems Are Executives Trying To Solve With Agile?

Written by Robert Galen on July 8, 2014. Posted in Articles. 7 Comments on What Problems Are Executives Trying To Solve With Agile?

Image Source: Imdb.com

Mike Cottmeyer is one of my favorite agile coaches and leaders within our community. When he worked for VersionOne years ago, I used to read his blogs fairly often. Now that he’s been out on his own with LeadingAgile, I don’t get the chance as often to experience his thoughts.

So I was pleased when I ran into a recent post by Mike that had the same title as this post. I read it with anticipation, and as with all of his writing, Mike made me stop and think a bit. Here’s a context snippet from Mike’s post:

Well then… if empowering teams, inspecting and adapting, and handling emerging requirements isn’t the problem execs are trying to solve… what exactly *is* the problem they are trying to solve. Rather than guess, I’ve gotten in the habit of asking them. Most senior leadership teams will say something like this…

- We are constantly blowing past commitments, we need a way to fix that and do what we say we are going to do.
- We are putting poor quality products into market, we think agile can help.
- We need more transparency into what is going on.
- We need more visibility into the progress we are really making on the product
- We need to get products into market faster.
- We don’t communicate very well, I hear agile can help us fix that.
- It costs too much to deliver software, we want to use agile as a way to lower the cost to product the product.
- We have way too much to do and not enough resources to get all the work done.
- Support work is constantly interrupting new product development

Much less frequently, we’ll hear answers like the following…

- We are trying to better understand our market and are putting out the wrong products
- We deliver on time, on cost, and on budget but the product wasn’t successful in market.
- We are looking for better ways of incorporating customer feedback in real time.
- We are looking for ways to continuously improve our processes
- We want to help people be more empowered to make decisions.

It’s not that this second group of answers aren’t important… it’s not that they never come up… it’s just that when they do, they are often secondary concerns. They are derivatives of first order concerns.

I’m actually not surprised that Mike is hearing the first list. Of course that’s what the majority of leaders are looking for. And I’m empathetic that they are searching for solutions to these challenges. When I was leading technology teams, from the late 1980’s thru 2012, I personally experienced all of them in a variety of forms. And frankly, it drove me crazy at times.

But what disappoints me a bit is the impression that they’re looking at “Agile” as a “Silver Bullet” that will address what are complex, organizational and systemic problems. These are problems that no mere framework or methodology will have a chance of resolving on its own. It’s this desire, and I may be overreaching a bit here, for a quick fix that disappoints me.

Why?

Because there are no Silver Bullets or quick fixes to hard problems. And any “fix” will require the engagement of this same leadership because most likely, they are a “part of the problem”.

To be honest, I get just as disappointed when leaders look at bringing in a tool or a consulting team as a panacea that will solve their problems as well. Sure tools can help and outside expertise is often valuable, but again, the leadership team needs to be “in the game” with the transformation and not just by paying the bills or initiating the idea.

Looking a Bit Deeper

Let’s take a few of Mike’s points that he’s hearing and drill into them a bit further…

We are constantly blowing past commitments, we need a way to fix that and do what we say we are going to do.

Absolutely. I agree. But, how are those “commitments” being made. Are your teams making them as you align them with your roadmaps and customer needs? Or are they simply being told what needs to be done by when by “management”?

You simply can’t force commitment and a simply having a job or receiving a paycheck doesn’t necessarily guarantee it either.

Instead, you want to enable a culture and environment where you support commitment and you support the process for your teams to get there. And part of commitment is acknowledging that things will change and there are no 100% guarantees. You have to be willing to trade things (scope) off as progress and discoveries are made. Remember, these are typically complex systems we are developing, which are notoriously hard to plan and predict exactly.

We are putting poor quality products into market, we think agile can help.

Why are you doing that? What do you mean by poor quality? In my experience, executives are often a factor here as they relentlessly drive the organization towards “more”, the message the team receives is that SPEED & DATES trump QUALITY. Agile will try to help with this, by reemphasizing quality deliverables at a team level. But delivering quality is typically hard work.

As a leader, you’ll need to “step down” and adjust your emphasis to be on quality over speed or dates. This may take a bit of time for your teams to realize the shift in your goals. But you’ll be surprised that when you successfully make this shift, with your teams, that you’ll get better quality and relatively increased speed as well.

We have way too much to do and not enough resources to get all the work done.

So if I get this right, a process model or type of SDLC will fix this how? This is the ultimate in Silver Bullet thinking. And beyond that, as a leader, you can actually do something here to help. You can either hire more people and/or prioritize the work so that the most important things actually align with your capacity. But clicking your heels together and hoping to “work smarter” or “get more done with less”, is never a viable strategy.

Agile, if implemented properly, it will force you to acknowledge the team capacity and ask them for the highest priority work that will fill their capacity. And yes, hold them accountable to deliver to their commitments to done software.

Support work is constantly interrupting new product development.

In many ways, support work is a side effect of our own doing. Clearly software isn’t perfect and has issues or drives usage questions. So support is indeed required. But my experience is that much of the support burden these executives are complaining about is driven because they established a culture where speed to market trumped doing things right and holding the line on product quality. Imagine that?

So when you don’t honor quality and release poor quality code, you get hit with high degrees of support and rework which derail your next release. And we all have heard of those repair cost models that discuss finding bugs by review vs. having your customers find them. It’s a pay me now or pay me later scenario. And most teams really want to deliver high quality code. It’s normally the business pressure and overall culture that forces premature releases.

What problems are executives trying to solve with agile?

All right, I may have rambled a bit too much, so back to the point.

I remember when I took my Certified Scrum Master certification with Ken Schwaber he said something along the following lines towards the end of the course:

People get frustrated with an introduction of Scrum thinking that it’s creating all of their problems. Scrum, or any of the agile methods, doesn’t create anything. But what it does do is show you your problems— often every day.

As a leader, it will expose to you organizational issues and other more systemic challenges.
As a team member, it will expose the impediments and realities of how well you’re delivering your software.
As a project manager, it will expose the faultiness of your planning and estimates, etc.

Then it’s up to you to do something about it. Reflect, examine root cause, and make a change. If you do you’ll improve. If you don’t, Scrum will bring it to your attention again tomorrow. It can be very frustrating—particularly if you’re looking for others to fix things for you.

So instead of creating problems, agility creates an environment where the problems are exposed and almost demand resolution. But not simply “team problems”. It will expose challenges that all levels of the organization need to face and resolve—including the leaders who have been giving Mike this feedback.

Wrapping up

Certainly I’m not dumping all of the responsibility on the leadership folks referenced in Mike’s post. I just want some of it to reside there. I’d much prefer that leaders move from silver bullet thinking to truly partnering with their teams. I’d also like them to take some personal responsibility to learn about the methods and the mindset of agility and to engage with it and their teams.

Additionally, I’d ask them to look at the problems that they identified as more holistic and systemic in nature and equally as much their problems as their teams. And finally, wouldn’t it be great if they rolled up their sleeves, with their teams, and got to work on improving things. And yes of course, as Servant Leaders and not Command-and-Control leaders.

Now is that too much to ask?

Stay agile my friends,
Bob.

Don`t forget to leave your comments below.