Summary

Since the writing of the Agile Manifesto in 2001, agile software development has made major gains in popularity. As I write this, that increasing momentum shows no sign of lessening any time soon. However, like all popular movements in business (or society), agile doesn’t always mean the same thing to all people. This is where the struggle to adopt agile software development begins. But couple the confusion stemming from what agile really means with a fundamental lack of knowledge of what kind of environment agile software development needs in order to be truly successful and what you have is the setup for a classic David (agile) versus Goliath (your organization) confrontation.

It would be gratifying to say that agile always wins that collision of ideas, but organizations with long histories also have quite entrenched viewpoints on how things should be and why. It is this entrenched monolithic resistance to new ideas and new ways of doing things that champions of the agile movement often find themselves in contention with. And, all too often, ill-equipped to combat, much less overcome.

It is exactly this state of affairs that set the wheels in my mind turning. Where does this resistance come from and why? Is there anything that we, as agile coaches and consultants can do before organizations attempt to adopt agile to create an environment where that adoption has the greatest chance of success? And after quite a lot of thought, I’d have to say that the answer is ‘yes’.

When an organization comes to me and boldly states that they have a mandate from their leadership to adopt agile, instead of allowing them to rush into a discussion on the specifics of how, I would, instead, like to turn the discussion toward their readiness to adopt agile. Because it is in their understanding of agile, their commitment to agile values and principles, and their willingness to change institutionally to empower agile software development that their success truly lay. To that end, I have researched and created 11 questions that tell me whether or not an organization is ready to being adopting agile software development and to what degree they will succeed.

1. Does Your Organization Have Continuous Integration/Continuous Delivery (CI-CD)* Capabilities?

If the answer to this question is ‘no’, then stop here. Your organization is highly likely to not be ready for anything even remotely resembling agile. This is because without CI-CD capabilities, then your organization likely has a choke point (i.e., a system constraint) at your deployment process. This choke point at deployment causes a backup which actively prevents development work (features, bug fixes, and the like) from flowing smoothly through the entire software development life cycle (SDLC). This, in turn, forces an organization to adopt a slow-paced, iterative SDLC that centers around releases. Once that happens, then everything becomes subservient to the release. Planning, budgeting, requirements gathering, development, testing, and deployment. It is not so much that software development cannot be staged in releases – it certainly can be – but without CI-CD capabilities, your SDLC is held hostage by your deployment process. Attempting to adopt agile from within a process that is already held hostage by a constraint will only exacerbate that constraint and frustrate your adoption of agile. In a nutshell, you’re likely better off adopting CI-CD first, then adopting agile.

*Continuous Integration/Continuous Delivery – automated build, artifacting, and deployment routines for your entire application stack

2. Does Your Leadership Truly Understand What Agile Means?

If the answer to this question is ‘no’, then stop here. That’s even if you truly know what their understanding of agile is. This question is particularly challenging, because when asked, most executives will swear absolutely that they do – even if they don’t. Some execs might even become incensed or offended when asked, so it’s likely best to approach the asking of this question delicately. One possible way to do this is hold a discovery meeting with an experienced agile coach where those execs can openly explore their understanding of agile.

You could start by asking everyone to take a few minutes and write down what agile means to them. You could follow that up by asking each person to tell you (and the room) one of the things that they wrote down, then write that down on a whiteboard. After going around once or twice, ask if anyone has anything written down that isn’t on the whiteboard and add that. Once all of that is out in the open, introduce the Agile Manifesto and start connecting what your executives have expressed with the Agile Values and Principles. What’s left over from their list, if it cannot be tied, either directly or indirectly, to those values and principles, call out, then cross out. Because those are the misconceptions that will ultimately hamper or even derail your adoption of agile. What’s left over from the Agile Values and Principles list are gaps. Those gaps are equally dangerous and lead directly into the next question.

3. Is Everyone in Your Organization Willing to Accept and Respect the Agile Values and Principles?

If the answer to this question is ‘no’, then stop here. Now that your organization’s leadership understands what agile really means, are they willing to abide by all of the Agile Values and Principles as if they were business rules? If they are, then great! If not, then each Agile Value and Principle that they cannot accept will become a potential point of failure in the organization’s adoption of agile. The trick here is to discover why your organization’s leaders are unwilling to accept certain of the Agile Values and Principles. It is these underlying reasons that create resistance to agile and prevent its successful adoption.

Just like the meeting above, the discovery of these underlying reasons for their resistance is a delicate matter and should be undertaken in the most open and nonjudgmental means possible. In fact, this discovery of these underlying reasons for resistance might well occur in the same meeting from above! Irrespective of when it happens, it will require a facilitator or agile coach who can step away from his/her role of championing agile long enough to simply listen (and record these reasons on the whiteboard). Once those reasons are out in the open, then they can be addressed, each in turn and still non-judgmentally, in an attempt to weaken or remove executive resistance to them. Only after your organization’s leadership is willing and committed to adhering to the Agile Values and Principles, even if only on an experimental or small-scale basis, will you be ready to proceed.

4. Is Your Organization Prepared to Transform ALL of Its Departments and Processes to Support Agile and Its Practices?

If the answer to this question is ‘no’, then stop here. The commitment of your organization’s leadership to agile will be sorely tested at this point. It is not enough for your development teams alone to adopt agile because all the other teams and departments that interact with them will also be affected. This is because agile development teams are organized differently than waterfall development teams. Agile development teams are intended to be autonomous and cross-functional within their assigned product, feature area or mission (i.e., performance optimization). The first resulting implication is that dependencies on other teams, departments or services should either be nonexistent or minimal at best. Each agile development team should be able to carry and idea from inception to delivery within their assigned product, feature area or mission. This means that personnel from other teams and departments will likely need to be moved into the agile development team. Instead of QA being a separate team or department, each agile team is given an embedded QA Tester that becomes a permanent part of that team.

Other positions, teams, and departments that are impacted by the adoption of agile include project managers, planning/budgeting, offices of project management, business analysts, development managers, human resources (because now you need to hire for agile development positions), business stakeholders, product managers and many, many others. Until your organization is ready to make decisions on how best to use all of these affected people (and processes that connect those people) in an agile development environment, you will not be ready to successfully adopt agile.

5. Is Your Leadership Willing to Relinquish Their Waterfall Metrics?

If the answer to this question is ‘no’, then stop here. Time, Cost, and Quality. These three things are known as the Iron Triangle of Project Management and are typically the most important constraints on any waterfall project. As such, these constraints are inescapable in traditional waterfall project management. The other important consideration is the traditional definition of a project. In that definition a project is a “temporary effort constrained by time, budget (cost), and quality, to bring about a specified result.” An easy example of this is building a house. However, in the traditional waterfall project management methodology, it is implicit for everyone involved to have all requisite domain knowledge before even the planning can begin. If all parties do not have all of the required domain knowledge, then the project cannot begin because all of the requisite tasks and their associated costs and durations are unknown. It is this uncertainty that often derails waterfall projects or causes scope creep, delays, cost overruns and the like.

Agile software development, on the other hand, is specifically designed to allow forward progress in the face of uncertainty by assuming that development is a continual, ongoing activity wherein work is constantly and repeatedly broken down into its smallest valuable units, estimated, and prioritized. Within the agile framework, cost/budget is not the primary constraint; rather business value is, followed by time to market and quality. Cost is still a factor, but it is no longer a primary factor. This is because development, and hence the development team, is seen as a sunk or ongoing cost. Features themselves become “projects” in the sense that they are temporary efforts, but development as a whole is an ongoing activity. In agile software development, the development team is relatively static as opposed to project teams that form for a project and disband after the completion of the project. Having static teams that learn from their past performance and increase productivity over time is another factor that influences cost in agile software development.

Knowing all of this, is your organization’s leadership willing to let go of the old waterfall metrics of time, cost, and quality in favor of business value, time to market (velocity) and quality (definition of done)?

6. Is Your Leadership Willing to Relinquish Their ‘What-By-When’ Mentality?

If the answer to this question is ‘no’, then stop here. ‘What-by-when’ is a favorite of business people the world over and is characterized by the questions ‘What can I have?’ and ‘When can I have it?’ This is intimately related to the time constraint, also known as the scope constraint, referred to in the previous waterfall metrics question. Why we are taking the time to address this individual constraint on its own is due to the fact that agile development teams do not engage in intensive and detailed long range planning because they consciously and purposefully confine themselves to ‘now’ and ‘next’. Typically, the only member of an agile development team that concerns him-/herself with long range planning is the Product Owner in cooperation with business stakeholders and/or end users.

This is not to say that agile development teams do not engage in any long range planning – that would be a truly erroneous statement. It is more true to say that the Product Owner creates the long range Product Roadmap and continually refines it into greater and greater detail the closer work items move toward ‘next’ and ‘now’. And if that becomes the focus of the development team, then it should likewise become the focus of the business leaders in your organization. Again, this not to say that they must give up long range planning – product roadmaps are great things – but they must be willing to let go of the kind of detailed, long range planning that waterfall project management calls for because it just doesn’t fit the needs of modern software development (like need for progress in the face of great uncertainty).

7. Are Your Project Managers Willing to Relinquish Their Command and Control Authority?

If the answer to this question is ‘no’, then stop here. Agile Coaches are not waterfall project managers. Scrum Masters are not waterfall project managers. Agile development teams are supposed to have a flat team structure so that they can focus on development and don’t get derailed by seagull managers constantly shifting priorities on them in the middle of a development cycle. That said, project managers, as well as the larger organizations that dictate their duties, have two options; adopt agile project management techniques or abstract traditional waterfall project management out of and away from the agile development process.

Project managers have traditionally been the “throat to choke” in regard to schedules and deadlines. However, in the digital environment, not all dependencies can be known up front, thus precise scheduling often cannot be engaged in with any hope of certainty – especially precise long-range scheduling. Often times, it requires a developer and a business systems analyst or product owner to sit down, discuss the requested functionality and document the workflow before any of the dependencies can be fully understood. Agile development handles this with two different mechanisms. First, the product owner meets with stakeholders, captures requirements, writes them as user stories and confirms them with the original stakeholders. Second, when more information is required, the product owner can work directly with a developer during a spike – a research period treated like any other user story – to discuss, understand, and document workflows and dependencies. This, in turn, may force the development team to break down the requested functionality differently and re-estimate it. However, after this happens, the requested functionality should be ready to pull into the next development cycle.

Knowing all of this, what command and control did project managers ever really have over the development process in the first place? Little to none would be one answer that comes quickly to mind. And the result, in the face of uncertainty and complexity, was always one of two things (or both!); long, stressful hours for the development team in order to meet a deadline that was set without regard for the uncertainty and complexity of the development being requested or slipped deadlines. In either case, the project manager was the responsible party and took the blame either from his/her own team or from upper management. And, please, take a moment here to note that the problem is not with project managers. Rather, these problems arise when waterfall project management techniques are applied to networked digital software products. Project managers are not the problem, the application of a project methodology that does not fit the context in which it is being applied is the problem.

That being the case, letting go of the illusion of control and precision in regard to timelines is the first step toward achieving success in software development. The next step is decreasing the batch size of development work. The final step is empowering the development team to tackle complex issues in ways that make sense to them. In lieu of a deadline for a swathe of functionality that is 6 months down the road, allow and empower the development team to focus on ‘now’ and ‘next’. And that means fundamentally changing the way organizations view project management in the digital context. It also means fundamentally changing the way organizations approach the duties of project managers assigned to networked software development projects. New metrics, methodologies, and approaches are needed – agile metrics, agile methodologies, and agile approaches. Until all of that old waterfall rubric is reimagined in the agile context, a truly successful adoption of agile will not be entirely possible.

8. Is Your Organization Capable of Forming Truly Cross-Functional Agile Development Teams?

If the answer to this question is ‘no’, then stop here. Agile development teams are meant to be both fully self-organizing and fully cross-functional. Cross-functional means that an agile development team is fully staffed to be capable of taking an idea from inception to full completion without going outside of the team. Self-organizing means that an agile development team is capable of organizing itself and its work to complete work without a manager assigning work and dictating approaches. Putting both of these concepts together also means that teams should be able to pull in resources that allow them to be fully cross-functional and self-organizing. This is part of what allows agile methodologies to create pull systems where development teams pull work from a list (the backlog), break it down, self-assign tasks and work it to completion.

These two aspects of agile development teams cannot be stressed enough. Each agile development team is intended to be a permanent team that develops deep domain knowledge around their assigned mission. They are also intended to be staffed with resources possessing all necessary skill sets from requirements gathering to testing to deployment. Each agile development team is intended to be a true team, a group of individuals coming together in a collective and collaborative effort to solve a problem and develop deep expertise while doing so. Development teams that are not truly cross-functional nor allowed to self-organize naturally require more management oversight than teams that are. It is this compartmentalization of work groups in traditional hierarchical organizations that produces inefficiencies and unnecessary organization complexity in the context of networked digital software development. A team that is properly equipped and empowered to take and idea and turn it into software is a team that will propel its organization forward. Conversely, a team that is siloed and micromanaged will only ever do what it is told to do because it is a team that is ill-equipped to do anything else. Until your organization is capable of creating independent, autonomous, cross-functional development teams, will not be truly successful in your adoption of agile.

9. Does Your Organization Have or Is Willing to Hire Agile Coaches with Experience and Expertise in Both the Practice and Adoption of Agile?

If the answer to this question is ‘no’, then stop here. The first eight questions focus largely on willingness in your organization at various levels, but predominantly at the upper levels of leadership and management where resistance can bring the adoption of agile to a screeching halt irrespective of what happens at the software development level. Once those conditions of willingness (and CI-CD) have been satisfied we can begin to turn our attention more toward organizational capabilities.

So, your organization wants to adopt agile? Does your organization currently employ anyone who already has well-grounded experience in agile? If so, then you need to leverage those people and their experience to your benefit. Do those same people have experience not just in using agile, but also in rolling out the adoption of agile in a business environment? If not, then you might still have a problem because adopting agile is no small change. It requires changes throughout the organization, from very top to the very bottom. It requires a unified vision and expertise that can only be gained from experiencing the wild roller coaster ride, resistance, and false starts that the adoption of agile almost always brings with it. This insight is invaluable and can often make the difference between a truly amazing adoption of agile and a half-hearted adoption that leads to mixed results.

If your organization does not already have people experience in both the practice and adoption of agile, then you will need to hire some – and these skilled individuals are rarely cheap. It almost always better to have a few of these individuals in your employ, but lacking that, hiring agile consultants to come in and train and/or certify the people that you do have is not a bad idea. But the entire idea behind all of this is create a unified working body of knowledge and practice of agile values, principles and methodologies that your organization can own and leverage moving forward. Without these people, either internal employees or external consultants, your organization will struggle. It will make all of the same mistakes that every other organization has made as they tried to adopt agile because they heard it was cool and jumped in without understanding the full implications of what they were doing.

10. Is Your Organization Capable of Naming and Truly Empowering Product Owners with the Necessary Business Acumen Required to Deliver Value to the Customer?

If the answer to this question is ‘no’, then stop here. If the answer is ‘I don’t know’, then stop here. First, let’s take a look at what a product owner is. The main responsibility of the product owner is to create work (user stories) that deliver value to the end user (the customer). It is in the delivering of value to your organization’s customers in a cost effective manner that success is realized, irrespective of whether that success is in the field of business, non-profit service, or government. And in order to understand what value you can deliver to your customers, you need someone who truly understands how what they want and what you do intersect.

Agile can be taught. It is true that deep understanding of agile doesn’t come free. It usually takes quite a bit of experience practicing agile until people begin to feel that they have a deeper understanding of it. But that doesn’t mean that you can’t start practicing agile without that experience – because you can! However, it can take years of experience to truly understand the ins and outs of an organization and what it does and how it does it. That experience is invaluable to a product owner. And it quite often comes at a greater cost than experience in agile. Remember, agile is a set of values and principles. Agile is an umbrella for software development methodologies that adhere to those principles. But in the end, agile is summed up by four values and twelve principles. Most organizations cannot neatly package everything that they do into such a neat and tidy package. The trick it to find someone who truly understands how to bring value to your customers, and hence success to your organization, and lay down agile on top of that.

If you have people like that, and every organization has at least a few, the next question to ask, is “Has your organization empowered these people to realize that value?” If these people are tied up in red tape, mired in bureaucracy, and bogged down by process, then not only is your organization failing to realize potential value, you are also frustrating these highly knowledgeable business people who will, in the end, seek an environment where they can realize value. These smart, experience business people will not be held back forever. We can either take the minimal risk required to empower them or we can frustrate them until they leave and we are left with the mess.

11. Are Your Leadership and Management Teams Prepared to Wait Until Your Agile Teams Reach the Performance Stage of the Team Development Cycle?

If the answer to this question is ‘no’, then stop here. Agile software development methodologies are, at their heart, empirical. That is to say that these methodologies are based on verifiable experience rather than on theory or conjecture. The implication here is that agile development teams must be allowed to practice agile development methodologies in order to create verifiable performance data that can then be used to make projections of future performance. That means that your organization’s leaders and managers will have to wait, allowing the development teams time to engage agile development practices (typically for at least three development cycles) before they establish metrics for success. This is often one of the scariest periods in the adoption of agile because it seems that there is little for these leaders and managers to do except wait until enough performance data is available for them to create meaning metrics from. If your organization’s leaders and managers are not willing to give your development teams this grace period, then there is a high likelihood that they are clinging to their waterfall schedules out of fear which will, however inadvertently, torpedo your efforts to adopt agile. Your best bet for success is to bring this up early and often and build it into your adoption plan. That way everyone will know what’s going on and why and when they will be free to begin creating meaningful baseline metrics for the individual development teams.