Product Manager

What we mean by Agile is becoming less and less clear. Rob Myers shares sixteen years of history and observation, noting the amazingly diverse ideologies and practices that people now include under this umbrella term. Agile started with the earliest notions of iterative-and-incremental, inspect-and-adapt principles and practices from Scrum. It now includes the intensive engineering disciplines of XP that have recently branched off into the Software Craftsmanship movement. Along the way, agile grafted in lean principles and saw the flowering of the elegantly simple Kanban approach.

As the software development lifecycle shifts toward agile and lean methodologies, quality in every build becomes critical. Continuous integration allows development teams to receive immediate feedback on their code, creating more efficiency and higher quality. After exploring the differences in continuous integration, continuous delivery, and continuous deployment, Jennifer Bonine and Michael Faulise discuss what is needed for their successful implementation, including the technologies and resources required at each stage of the process.

Continuous delivery in software development allows us to deliver incrementally, get quick feedback, and react. A key enabler is the adoption of agile techniques and methods; key inhibitors in the enterprise are size, scale, and complexity. The Rational ALM organization is a typical enterprise, and our teams have (mostly) adopted agile principles. But agility at enterprise scale is not the same as team-based agile development. Now we must coordinate work across multiple interdependent teams to deliver value, rather than focusing on developing a single product or application.

In today's rapidly changing environment, organizations—both large and small—must quickly respond to shifting market requirements to remain competitive. To be successful, many are adopting agile development and continuous delivery methodologies to deliver software quickly, while keeping the quality and maintainability high. Several years ago the WebSphere Application Server development teams embarked on the journey from traditional waterfall development to agile. They are now expanding to use both agile and continuous delivery methodologies across their organization worldwide.

Distributed work is common today, and often the talent you need is in another geographic location where time zone differences can impede communication. Building seamless collaboration across distributed teams to support development and operational initiatives can seem impossible—even for the most experienced technology leaders. So, where do you start? How do you organize and manage distributed development and operations when traditional silos exist? Bill Krebs, aka AgileBill, will discuss six categories of tools and six practice areas to help you leverage today’s global talent.

One of the core functions of a PMO is to help an organization standardize efficient processes to select and execute strategic projects. Unfortunately, many PMOs are finding themselves struggling to justify their own existence. In a recent survey, more than half of the respondents reported that the value of their PMOs is in question. By using a one-size-fits-all approach to best practices, we may set our PMOs up for failure, holding them accountable for predicting the future. There is no magic crystal ball!

Teams in many organizations are still expected to produce and maintain significant amounts of documentation. This is generally the case in Federal, state, and local governments where systems must comply with SOX, HIPPA, NAIC, FDA, or SEC directives. In recent years, Agile has made substantial inroads into government and other heavily regulated environments. However, some successful projects have been criticized for failing to generate the expected documentation.

Behind every successful delivery to a customer, there is a well-run, cross-functional team. They trust each other; they work well together. Yet every team, agile or not, faces the challenges of building such a team. And, despite their best efforts, many teams fail in this attempt, never fully realize their full potential, and are unable to deliver the best possible value to their customers. Fuming Ye discusses the foundations to build a high performing team: an agile team’s responsibilities to each other, problem ownership, and the discipline to execute.

Information technology (IT) projects are notorious for exceeding budget and schedule estimates, and high visibility failures are common. IT projects in the public sector are particularly challenging. State, provincial, and federal governments worldwide have sponsored noteworthy disasters in the past twenty years. As agile methods have evolved, become more mainstream, and demonstrated their value in the private sector in the past decade, they are often cited as a remedy for the public sector’s IT misery.

In our personal and business lives, many of us know leaders who successfully foster environments of incredible creativity, innovation, and ideas—while other leaders try but fail. So, how do the top leaders get it right? Going beyond the basics, Pollyanna Pixton explores with you the ways that the best leaders create “safety nets” that allow people to discover and try new possibilities, help people fail early, and correct faster. Removing fear and engendering trust make the team and organization more creative and productive as they spend less energy protecting themselves and the status quo.

No more managers! No more hierarchy! A truly self organizing, self-running team! These phrases strike fear into managers almost as much as: We are moving to agile. As successful companies like Zappos, GitHub, and Treehouse discard managers from their teams, other software managers are left wondering about their futures. The reality is that managers are even more relevant and necessary today—if they transform from command-and-control to a coaching-style role. Employees need to know they have an advocate—not just in the business but in their careers.

Organizations are often reluctant to adopt the more challenging agile engineering practices—first seen together in Extreme Programming and later adopted by the Scrum Alliance as the Scrum Developer Practices. These practices are difficult to implement and sustain, and the benefits are often vague, subtle, and measurable only after months of disciplined effort. For an engineering practice to provide real organizational value, it must effectively address real throughput constraints.

The evidence is in—and it's compelling. Well-executed agile practices can shorten software project schedules by 30 percent while cutting defects by 75 percent. However, many organizations struggle with agile adoption. And some of these struggles can be attributed to the executive leadership. In many cases, the "lead, follow, or get out of the way" attitude causes executives to try to lead when they should be following or getting out of the way.

Many enterprises are trying to create a more predictable flow, achieve ROI faster, improve quality, and be more responsive to the market. To this end, they attempt to transform to team-based agile, and then leverage scaled agile models to govern how requirements are defined, decomposed, coordinated, and tested. However, many of these efforts prove ineffective, and organizations fail to realize hoped for business benefits. In complex organizations, interdependencies between team design, architectural design, and governance contribute to this problem.