Read more]]> Big Agile is “agile as far as the eye can see.” It is not “one Big Agile organization.” The distinction becomes clear when you consider the context of size: team versus whole organization. While it is certainly possible, and desirable, for a company as a whole to be influenced by agile practices and principles, that doesn’t mean that agile alone can make a whole company move more quickly and easily.

Agile, as both a theory of management and of software engineering, is tuned very well for one to several teams of individuals working closely together. Beyond that scale, agile alone won’t address all organizational challenges — no agile transformation initiative alone could do so. Solving larger-scale problems will require other management and engineering methods, some of which I discuss below.

When companies grow beyond a handful of individuals or teams, many changes will affect the organization of work and people. One of the first results of large scale is decreased information sharing, both across teams and for individuals joining existing teams. At small scale, and for a limited period of time, a team can organically “remember” its own history. Beyond that small scale, though, organizations need to promote mechanisms that encourage learning and sharing across the organization.

Mentoring

Today’s organizations are heavily focused on knowledge work — the creation and application of knowledge. It is truly the people that are the most valuable resources. Learning can’t be rushed or accomplished in a quick orientation. The 10,000-Hour Rule says that it takes approximately 10,000 hours of deliberate practice to master a skill. That is about five years of working full time at something in an environment where feedback and progress can occur.

Mentoring is a mechanism for long-term leadership and growth. It encourages learning and transfer of knowledge within and between parts of an organization. Mentoring is used extensively in Japanese management, and it is the foundation of craft and artisan learning. In such organizations, everyone has a mentor who assists and actively guides them.

Value Stream

Beyond the challenges of sharing information effectively, organizations at scale frequently structure into functional silos. This is often the result of focusing on efficiencies of scale in the attempt to keep individuals fully utilized and working on the most appropriate tasks. This functional efficiency comes at the cost of cycle time and responsiveness, though, and it doesn’t account for the cost-of-delay economic tradeoff.

Value stream-based organizations will optimize for the flow, and reduced cycle time, of valuable product features. Instead of trying to maximize efficiency of any one function, this approach measures the whole system while trying to reduce total time to delivery. In this method of managing work, deep queues of work don’t exist to cause significant delay.

Aligning toward the customer and stream of value promotes another benefit for individuals and teams: it is easier to define a vision and more motivating for people to work toward that vision when they can connect themselves with delivering actual value to real customers.

Risk Management

Planning work at scale involves committing resources with energy and momentum behind them, often with a fairly detailed budget for a fiscal year or more. This commitment creates an inertia that is a particular challenge for agile teams, which by definition assume the future is going to change, yet are pressured by a static plan.

Risk management can be applied during yearly planning cycles to projects and technical investments alike. Assuming “economics is an exchange of risk and opportunity,” we can conclude that budgeting and financial planning activities should account for the temporal nature of both risk and opportunity.

At smaller scales, risk management can be as simple as creating what-if scenarios, but as investment and commitment scale, so too should risk management. Such topics as technical debt, new or old technologies, competitive landscape, and so on, should all be represented in the planning cycles to mitigate the risks posed by the unknown. It may be very appropriate to take a risk, but it is never appropriate to forget about the facts — your economic outlook depends upon it.

Real Options Theory

In addition to avoiding or mitigating risks, deferring the planning or execution of work until the appropriate time is a planning option that can be used effectively at any scale. Real options theory holds that options have value, and options expire. Never commit early unless you know why.

Options thinking encourages us to delay commitment instead of trying to lock things down as soon as possible. This delay improves our position by giving us time to acquire more information and, when it’s time, make a better decision. This style of planning blends well with agile teams: both the decision making process and execution evolve together over time.

Evidence-Based Management

Finally, in a large-scale environment where it’s all too easy to be less connected with customers, colleagues, and other teams, it is even more important to pursue empirical data of what is truly needed and actually happening.

Evidence-based management is the “conscientious, explicit, and judicious use of current best evidence in making decisions.” There is a long pedigree of methods based on this idea:

• W. Edwards Deming taught using data to make decisions in TQM.
• The Toyota/Lean process has both “go to the source” (the Japanese word gemba means “source,” or where the work is actually being done) and data-driven continuous improvement toward target conditions.
• OODA/maneuver warfare teaches both gathering information and making decisions with imperfect information. (John Boyd defined the OODA [Observe, Orient, Decide, Act] loop for fighter pilots while a member of the US Air Force. It is now a theoretical basis used in maneuver warfare.)
• The Lean Startup method is strongly focused on growing knowledge through experiments.

This is the scientific method applied to business and management: have an idea, experiment to prove it out, then either alter the idea or invest in it. Agile teams are very good at doing exactly this sort of experimentation and changing direction based on the results. Overly lengthy and detailed planning horizons or “hope-based” management (which skips right from idea to investment, skipping over any real validation) often leads to death march projects.

Read more]]> Quite a few clients report that agile is anti-innovation. The developers have a vested interest in developing whatever they can produce within the allowable time. They are rewarded for maintaining the velocity of the project, not for their innovative solutions. Note that innovation, as we use the term here, means fresh thinking. We do not mean that innovation is the same as invention — it’s not. Innovation is thinking differently about the business problem with the intention of finding more beneficial things for the business to do.

User stories that are not based on real business stories will struggle to be innovative. The user story describes what happens at the interface and is mostly what the product owner thinks the user wants to do with the software. But without some innovative thinking, it is all too easy to provide just some incremental improvement and let it go at that. Let’s look at an example of a user story that was written without any real concern for innovation or the real need that the story is meant to satisfy: “As a bank account holder, I want to check my balance online.”

At first, this might seem a reasonable and obvious story. However, it can be made a lot better. Some authors suggest that the “so that” part can be omitted. We suggest very strongly that you always include the reason in your stories. While the Agile Manifesto favors working code over documentation — and there is a lot to be said for that — there is nevertheless a need for the development team to leave behind a guideline of its thinking. Without justifying the requirement — that means including the “so that” — future maintenance teams are deprived of a valuable clue as to why a particular requirement was included in the software product and, hence, what would be the effect of changing it.

Our first question is, “Why does the account owner want to check the balance?” Let’s revisit the story and this time look at the reason given for the requirement: “As a bank account holder, I want to check my balance online so that I can access my daily balance 24 hours a day.”

This is not exactly a good reason for checking the balance. The “24 hours a day” is slightly more enlightening but doesn’t really do more than tell us that the account owner might have nocturnal habits. Why does the account owner wish to check the balance? It is not something we do for fun, so there probably is some business reason behind it. We just don’t yet know what that is. Let’s make some conjectures.

Suppose the reason for the frequent checking is that the account owner is on a tight budget and is concerned about becoming overdrawn. If so, the owner of the product, presumably a bank, has the opportunity here to be more effective and at the same time provide a better service. Instead of the account owner having to repeatedly check his or her balance to see that it’s not going into the red, it would be better to build a feature that notifies the account owner if the normal monthly payments such as rent, electricity, school fees, and so on, will reduce the account balance to zero or beyond: “As a bank account holder I want to be informed if my monthly balance is projected to go to zero or below so that I can arrange for an overdraft.”

Furthermore, we suggest that it is far more useful for the account owner to be periodically informed of the amount of discretionary money in the account: “As a bank account holder I want to be informed of my projected balance after all regular monthly payments have been deducted so that I know how much I can safely spend.”

Having a feature that lets the account owner check the balance online is the simplest feature to have. However, we suspect that without any kind of business thinking, or innovative thinking, it would probably turn out to be a feature that did not solve the real problem. If other banks solve the real problem (i.e., they understand the real needs of their customers and offer this service to attract more customers), then the original story could hardly be said to providing real business value.

When a business analyst investigates a business story, he or she is consciously trying to encourage innovation by first making abstractions that uncover the real business problem. Figure 7 illustrates the skill of looking at the same business story from several different points of view and thereby discovering undreamed of innovations that could make a significant difference to the business.

Figure 1 — The Brown Cow model illustrates four points of view that help to uncover the real business problem and identify useful innovations.

In the bottom-left quadrant of the Brown Cow model 6 the viewpoint focuses on how things are done now. This is commonly what business people ask for — a little bit more of what we already have. In the bottom-right quadrant the viewpoint focuses on how things could work in the future. Once again, it is likely that someone who has a requirement will express it in these terms. In other words, like our nurses in the previous example, rather than asking for what they really need, they ask for a solution.

As part of his or her analytical skills, the business analyst also learns to explore the problem in a solution-neutral fashion. We refer to this as the ability to “think above the line.” The line in this case is the horizontal line that separates the top and bottom quadrants of the model — the abstract thinking about the real problem from the technological view of the solutions.

The top-left quadrant focuses on what we do now, independent from how it is done now or how it might be done in the future. This view uncovers the essence of the problem: the business rules and the business data that has to be there independent of any solution. Above the line, the business analyst exposes the real business requirements by stripping away all solution-oriented aspects and thereby coming up with a policy-only statement of what the business is really doing. The top-right quadrant of the model is where the business innovation happens. It is here that the business analyst can make suggestions about improving business rules or using existing business data to be able to make better business decisions.

Innovative business value discovered by this sort of innovative thinking are then included in the business stories. These are innovations that could never be discovered by focusing on a software interface.

Read more]]> It often starts as a seemingly plain training request. Having decided to go the agile route, a client would like Cutter to train a certain number of employees in one agile method or another. We collect data on the demographics of the target population: architects, UI designers, product managers, project managers, developers, testers, and so on. We then move on to discuss the way these folks are geographically dispersed and what the team structure for the launched agile teams will be. Once these parameters have been nailed down, it largely becomes a matter of figuring out the logistics for training and coaching. A fairly straightforward process for rolling out the agile process, one might say.

The catch, time and time again, is that the problem to be solved had been defined from the outset in too narrow a manner. Naturally enough, a client wrestling with software challenges tends to gravitate toward improving the software method(s) in use. It is a small step from here to the conclusion that effective training and coaching are the only services that really need to be provided by the consultant(s).

The typical outcome of such a narrowly defined engagement is improved tactical agility. The teams become quite good at responding to frequent change needs. Stories get added, modified, deleted, or reprioritized fairly effectively and (many times) efficiently. The improvement can be assessed, and very possibly quantified, in quite a few ways. Yet, it is quite difficult, if not impossible, to point out the actual business benefits. The improvement in the process is clear enough to anyone who cares to examine it, but the end-to-end functioning of the software still leaves much to be desired. The “so what?!” question is typically raised under such circumstance: could it be the case that the resources put into the agile initiative could be better invested elsewhere?

My view on the subject — before, during, and after the engagement — is that an improved software process is a necessary but not sufficient condition for attaining the desired business results. Obviously, elaborate business plans are next to impossible to implement if the software process crumbles underneath them. However important tactical agility through a robust agile process is, it cannot on its own address strategic adaptability nor supply-demand alignment issues. To succeed as a business from a software perspective, you need all three: agility, adaptability, and alignment.

Lack of strategic adaptability is the end result of the accumulation of all “sins” that had been committed “against” the code prior to starting a new page with agile. The investment you put into improving the software process will probably pay off nicely in terms of quality, productivity, and time-to-market at some point in the future. Unless the level of your technical debt on the existing code is really low, however, your overall software system — old in combination with the new — will be slow to adapt. In addition to investing in agile, you will need to invest in pushing down the level of technical debt that had accrued over the years. You might choose to think of the investment in agile as primarily forward-looking. In contrast, cleaning up the technical debt mess might (erroneously) seem like backward-looking. However, both need to take place. As a matter of fact, doing the two together is quite synergistic, as technical debt is an excellent metric for driving agile software development.

If you step back to examine how the technical debt accumulated in the first place, you are very likely to find out that the vicious cycle depicted in Figure 1 has been taking place for years on end. It is not lack of expertise or the difficulty of development across the pond that got the software in trouble (though these might be contributing factors of secondary importance). Rather, it is the inevitable system dynamics that prevail when supply (i.e., team capacity) is misaligned with demand (i.e., requirements).

Figure 1 — The vicious cycle of technical debt.

Aligning supply with demand is in many ways the acid test for the long-term success of your agile initiative. Our knowledge of the agile process has increased dramatically over the past 10 years. Likewise, progress in technical debt measurement, reduction, and prevention has been quite impressive during the past couple of years. We know enough about agile methods and technical debt techniques to improve the state of affairs in all but the most desperate situations. As Figure 1 illustrates, we also possess a fairly good understanding of how misalignment could lead to the accumulation of technical debt of biblical proportions. What are often lacking are the discipline, will, and determination to force alignment.

My recommendation on supply-demand alignment in the sense defined in this article is to use the data structure of the enterprise depicted in Figure 2 as the tool for forcing alignment at multiple levels of abstraction. The principle is simple: the grand total of development and technical debt reduction work (probably expressed as dollars) at the epic level can’t exceed the amount allocated at the respective theme level. Likewise, the grand total of development and technical debt reduction at the feature level can’t exceed the amount allocated at the respective epic level. Ditto for the story level: the grand total of development and technical debt reduction at the story level can’t exceed the amount allocated at the respective feature level.

Figure 2 — Data structure of the enterprise.

You can opt to traverse the data structure of the enterprise in a top-down manner or in a bottom-up fashion. Whatever direction you choose, you must maintain the integrity of the calculations (i.e., the grand total in one level can’t exceed the respective allocation in the level above). Maintaining this integrity is quite possibly the number-one responsibility of the stakeholders you pick to govern the software process in your company.

– Israel Gat, Director, Agile Product & Project Management Practice

Read more]]> Since we announced the forthcoming “Big Agile” webinar (click here for details), I have been exposed to numerous questions and comments about “Big” vis-a-vis “Lean” in the Agile context.  The intensity of some of these discourses was so high that I decided to comment on the subject in advance of the webinar. A lively debate during the webinar is, of course, goodness. In contrast, starting the webinar with a potentially gross misunderstanding as to where we are coming from and where we are heading is not too desirable.

In general, “big”, to me, can be “lean”. As a matter of fact, big should be lean as otherwise scale will quite possibly pose a problem.

Specifically, in the Agile context I expect “Big Agile” to incorporate various elements of Lean. For example:

• Utilize Value Stream Mapping
• Measure Cycle Time
• Apply Work in Process (WIP) limits

Examining software methods over the past few years, I actually interpret the evolution of both Agile methods and Lean techniques as elements of a much bigger trend. Software development is moving closer to the business and becoming better aligned with the business. Value stream mapping, continuous integration (which enables continuous feedback), and the driving of software development through strategic investment themes are all part of a pattern: the walls between development and the business are coming down. As a matter of fact, the walls between development and other departments are coming down. Such breaking of the walls that had created silos is most obvious today in devops, but it is starting to happen in marketing, professional services, customer support and elsewhere.

Juggling on the Berlin Wall (source: Wikipedia)

I have a strong feeling of deja vu as I write this post. It took system management quite a few years to align IT with the business through Business Service Management (BSM). IMHO the same kind of growing pains we had experienced back then with respect to system management are simply re-manifesting themselves now as we align software development with the business.

Stay tuned – Hubert Smits and I will say a lot more on the subject(s) during the January 30, 12 pm EST webinar.

Read more]]> It would seem that the devops discussion is mostly driven by development’s incentives, and appropriately so, given developers’ focus on building functionality for the business user. So it’s no surprise that development is the originator of the whole devops lifecycle, but are there any dangers lurking in a one-sided focus on devops issues?

A hefty majority of devops articles come from writers of the development persuasion who are motivated by the legitimate frustrations of the application deployment process. The movement to agile development has been a key contributor in the increase of handicaps encountered as a result of more frequent transitions from development to operations IT groups. Online and verbal discussions identify the primary challenge as getting IT operations to be more creative and flexible in their approach to changes coming from the application development discipline.{1}

Given its critical involvement in deploying new and enhanced applications, why hasn’t IT operations been more active within the devops movement? Given the opportunity for IT operations to be more effectively heard by its primary IT companion organization, why hasn’t IT ops been more responsive to devops strategic initiatives? Given that changes to the operational model are almost guaranteed, why isn’t IT ops more proactive in anticipating such changes? Given the need for more effective alignment with the business user, whose automation needs are frequently accommodated by inhouse development, why hasn’t IT ops seized the chance to leverage this obvious path to improving IT’s core value proposition to end-user communities? I’ve heard many theories, but few have resonated.

Devops is a maturing discipline and is obviously offering an increasingly visible value proposition for the enterprise. This growing devops “maturity” is driving more effective partnerships and better integration opportunities. That’s the good news. The bad news is that the devops partnerships and integrations are not coming fast enough to appease the significant IT market demand. One proof point is the rapid escalation in demand for SaaS application deployment, which is a symptom of the ongoing struggle between development and operations groups in satisfying end users’ business demands. Competitive options now exist (and are expanding) for businesses to choose alternatives to IT-delivered and -supported applications, which further fuels the customer’s questioning of IT’s contribution to achieving corporate business objectives.

“Services” Mindset of IT Operations Essential to Devops

Fundamental to understanding the mindset of IT operations is its emphasis on delivering and maintaining “services” that are of value to the business community.

Solutions to business problems and support for business models, strategies, and operations are increasingly in the form of services. The popularity of shared services and outsourcing has contributed to the increase in the number of organizations who are service providers, including internal organizational units. This in turn has strengthened the practice of service management and at the same time imposed greater challenges upon it.{2}

An essential requirement for devops success is to think of, prepare, implement, and support the new application as a mandatory component of a service that is being offered to the business customer. That service is positioned as having an intrinsic value that is broader than the application by itself; as a result, the business executive can easily identify it as critical to achieving business goals. IT operations brings a rich experience of managing those services to devops initiatives. Ops needs to be more aggressive about sharing that unique perspective at the same time that IT development needs to be more attentive to those IT service management (ITSM) best practices that are documented, promoted, and used on behalf of devops by its core practitioners.

IT operations has struggled for decades to deliver more and more technology services with fewer and fewer resources — and is actually doing a fair job.{3} Fundamental to that achievement has been a focus on ITSM best practices specifically designed for improving the operational alignment between IT and its business customers. These guidelines and processes have been captured and documented by leading ITSM professionals for the Information Technology Infrastructure Library (ITIL), funded by the UK’s Office of Government Commerce (OGC).

As a starting point for understanding the mindset, roles, and values of IT operations within the devops discussion, ITIL V3′s focus on delivering business value through more effective IT services is invaluable. ITIL positions these best practices as “based on expert advice and input from ITIL users [and] … both current and practical, combining the latest thinking with sound, common sense guidance.”{4} The success of that “common sense” approach has contributed significantly to the rapid acceptance and global implementation of ITIL V2 and V3 by ITSM organizations over the last 10 years.

Bridging the Devops Gap

So what might the operations perspective on devops initiatives be? I would offer that ITIL’s V3 Application Management (AM) function {5} is probably one of the more useful resources available for describing that operational viewpoint. It is written as a set of best practices or guidelines for supporting …

the organization’s business processes by helping to identify functional and manageability requirements for application software, and then to assist in the design and deployment of those applications and the ongoing support and improvement of those applications.{6}

As such, ITIL AM is designed to help bridge the devops gap and articulate some of the common language or terminology now lacking between the development and operations organizations.

As a process improvement approach, the Capability Maturity Model Integration (CMMI) has become a highly successful, best practice model for software engineering. CMMI is a set of process guidelines driven primarily by development’s need to deliver applications of value to the business user and secondarily by how the end customer uses the application as a service to achieve business purposes. This is a subtle yet critical distinction. The CMMI model does not adequately address the service mentality and service priorities of the IT operations organization, which has fully embraced ITIL for that role instead.

In the August 2011 issue of Cutter IT Journal, Bill Phifer of HP Enterprise Services created a compelling case for embracing a host of ITSM processes, with the ITIL Service Lifecycle becoming the needed counterbalance to the development perspective that is incorporated and respected within CMMI (see “Next-Generation Process Integration: CMMI and ITIL Do Devops,” Vol. 24, No. 8). The strength of ITIL is its unrelenting emphasis on “serving” the needs of the business community and adapting any IT deliverable to the “whole” of the system — as perceived by the business customer, not IT operations. For devops, this requires a correlation of management processes and tools that can address the demands coming from end users, business functions, and technologies as well as applications. ITIL in its intended form {7} does not create a focus on IT management processes for the sake of IT personnel. An ITIL-oriented project fails miserably when such an IT-only focus happens.

Notes

¹ Read, Chris. “DevOps: State of the Nation.” Agile Web Development & Operations, 30 November 2010.

² Introduction to the ITIL Service Lifecycle. ITIL V3. Office of Government Commerce (OGC), 2010.

³ McAfee, Andrew, and Erik Brynjolfsson. “What Makes a Company Good at IT?” The Wall Street Journal, 25 April 2011.

⁴ITIL (www.itil-officialsite.com).

⁵ ITIL Service Operation. ITIL V3. OGC, 2007. (ITIL published a “Summary of Updates” in August 2011; see www.itil-officialsite.com.)

⁶ ITIL Service Operation. See 5.

⁷ Fry, Malcolm. ITIL Lite: A Road Map to Full or Partial ITIL Implementation. The Stationery Office, 2010.

Read more]]> Given the current interest rate situation and demand for US currency, the US will see much more business expansion through 2013. Once the world realizes we are not really any better off than Greece (in terms of debt/GDP), we’ll see inflation, business retraction and possible recession. Companies interested in surviving the 2013 – 2018 recession would be wise to invest in going Agile as soon as possible and holding the cash they save in the process to buy out those companies that weren’t so smart.

[Editor's Note: This post is part of the annual "Cutter Predicts ..." series, compiled at the Cutter Consortium website.]

Read more]]> Immerse yourself in Agile on day three of Cutter Consortium’s Summit: Executive Education+, 2-4 April 2012. You’ll find out how Agile, the software method that was conceived as a way to cope with change, is changing, how these changes can benefit your organization — and what you need to do to make that happen. Agile practice director Israel Gat has assembled an impressive team of Cutter consultants to present, including:

• Patrick Debois: What Leaders Need to Know About Devops
• Jim Sutton: Reclaiming Business Glory through the Lean Worldview
• Hubert Smits: Want to be Radical? Here’s How
• and Israel himself: Agile 2.0: Change is Changing!

Limited-time Registration Savings

Like 2011, our best offers for Summit 2012 won’t last. Register now to bring two team members for the price of a single registration (save $1995) or purchase a single seat for super early-bird savings of $1595 (save $400).

If you’re waiting on 2012 budget, but would like to take advantage of these savings, choose “Bill Me” and pay in 2012!

In addition to the stellar Agile program, you’ll benefit from the world class executive education the Summit is known for — keynotes, interactive case studies and exercises on leadership and teaming delivered by Cutter Fellows and distinguished business school faculty, as well as interactive work sessions built around emerging topics and technologies that matter to business technology leaders. You’ll enjoy (and join in on!) raucous panel debates moderated by the inimitable Tom DeMarco, networking at lunches, breaks, and entertaining evening events; and get one-on-one guidance and input from expert presenters and participants.

P.S. If Agile isn’t your area, you can choose from three other in-depth Wednesday programs — enterprise architecture programs that work, agile analytics, and a CIO roundtable work session. Check out the full agenda!

Read more]]> Last year I predicted that 2011 was to be the beginning of a shift from a focus on quality, schedule, and budget to value, quality, and innovation. Presentations at diverse conferences around the world show that there is an increasing interest in value and quality, and to some extent, innovation, too.

The interest in value and quality was boosted in part by Jim Highsmith’s Agile Triangle (see Jim’s webinar Measuring Agile Performance: Beyond Scope, Schedule and Cost Webinar and his book Agile Project Management, 2^nd Edition). A few months after Jim’s book came out in 2010, I published the first version of the Lean–Agile Prism in the Agile Journal, where I added design as a fourth element; that element evolved throughout that year to innovative design and, eventually to innovation. (I also wrote about this in the Cutter Executive Update, “The Agile Triangle Evolves as a Lean-Agile Prism”.) Why the evolution? Because innovation makes it easier to increase quality and value.

During 2012 we will see this trend continue. Lean and Agile thinking, together with methods such as Kanban and Scrum, will greatly contribute to a better understanding of value and quality. Teams and organizations will begin to understand that innovation goes beyond highly visible products such as the iPad; innovation has more to do with improvements (at all levels of the organization and in all contexts) and that the longtail of innovation provides greater benefits than, for example, the 20/80 Pareto approach.

This shift in the way of thinking will help decision makers and customers understand that managing projects based on budget, schedule and time doesn’t match the effectiveness of managing projects based on value and quality and allowing innovation to take place as services and products are developed.

I don’t expect full awareness to take place during 2012 but I do expect to see a tangible shift in this direction by year’s end.

[Editor's Note: This post is part of the annual "Cutter Predicts ..." series, compiled at the Cutter Consortium website.]

Read more]]> Last year, my colleagues and I predicted various changes: an increase in this, a let-up in that. I finally understand why I have been struggling to come up with my 2012 prediction: I am just not seeing any changes. Let me elaborate on this for my specialty — Agile/Lean software development.

I predict that many organizations worldwide will continue to adopt Agile. Most of them will do so with no expert guidance, with ho-hum results, and with little understanding of why they got those results. People will continue to get their Agile skills certified while others rail against the value and implication of those certificates. Companies will still rely on head hunters to hire Agile coaches, and wonder why those coaches can’t seem to straighten out their Agile implementation. Organizations will continue to agonize over micro-estimation of detailed backlogs. They will continue to spend a pretty penny on “adding bodies” to projects riddled with technical debt, while not investing in the skills and habits their developers need to reduce or avoid increasing such debt. Managers will continue to use language like “We just hired a resource in development” without investing proper attention in the hired person. And downsizings will continue until morale improves.

[Editor's Note: This post is part of the annual "Cutter Predicts ..." series, compiled at the Cutter Consortium website.]

Read more]]> I see the demand for actual performance results over declarative symbolic victories (e.g., certifications) taking a significant bend upwards. I’ve already begun to see the more forward-thinking companies maturing in their thinking about how they use “named” business, technology, and management concepts, e.g., Scrum, Lean, Kanban, CMMI, ISO 9000, ITIL, COBIT, Devops, etc. There’s growing skepticism in the efficacy of popularized approaches. Executives are less likely to rush into using new ideas just because they’ve heard “the name”. Whether they’re skeptical for the right reasons or not, their cautious approach offers a better have a chance of implementing these “named” initiatives effectively, keeping them off their list of failures – a list that contributes to the skepticism in the first place.

[Editor's Note: This post is part of the annual "Cutter Predicts ..." series, compiled at the Cutter Consortium website.]