Why Agile Project Management? I was recently rereading one of my earliest e-mail Advisors from this Agile Project Management Practice (it was actually e-Project management then). The Advisor was about why this different way of managing projects was so important. After reading it, I decided it was time to revisit and update that issue. One company struggles with a large project with critical time constrains and ever-shifting requirements. One and one-half million lines of code -- in a cell phone, and that's just the beginning. "My project has critical time constraints and the requirements are evolving constantly (brought about by changing industry standards) during the project, because of turbulence in the wireless telecommunications market, so that generating and maintaining the range of documentation required for a typical corporate project would doom this one." A company with an extensive human resource product line struggles with growth (over 500 engineers), rising complexity, and demanding customers. A functionally oriented organizational structure (product management, development, QA) and expanding feature requirements limit necessary collaboration and lead to slipping schedules and quality issues. A worldwide, multibillion-dollar media company struggles with new product introduction as Web-based delivery platforms evolve and competition requires innovative and easy-to-use new products. Innovation, complexity, change, size, uncertainty, growth, globalization, and more are factors that software development organizations must deal with today. Historically, development methodologies dealt well with one or two of these dimensions but not with all. Traditional methodologies dealt well (sometimes, at least) with large size and complexity, but not well with innovation and change. Rapid development methodologies of the early to mid-1990s dealt well with innovation and change but not well with size and complexity. A software development methodology is actually a strategy for success, and as such must prioritize objectives. An agile approach builds on a common framework of principles and practices, but even more important, one of those principles encourages us to adapt to change; to adapt to different objectives and constraints on a project. However, given the business environment today, there are certain challenges for which agile development excels. The number-one challenge of agile project management is creating a culture of innovation -- everything else pales in comparison. Agile projects often attempt to implement the new, the untried, and the nearly impossible -- this is not the problem domain in which controlling tasks to achieve a fixed plan will succeed. This is a problem domain that demands the innovative exploration of possibilities. The underlying assumptions of traditional project management are predictability and control: project managers expect progress to mirror the plan, and they expect to exert firm control over that progress. Whereas traditional practices focused on the mechanics of scheduling, task planning, and monitoring, agile project management focuses on innovation, collaboration, decision making, knowledge management, fuzzy planning, and exploratory development. In that earlier Advisor, I defined agile projects in the following way: Agile projects are large projects that must be delivered rapidly, that are both research-like and mission-critical, and that have to be managed in a turbulent business and technology environment. The statement is as valid today as it was five years ago. There are quite a few significant words in the statement: rapidly, large, research-like, mission-critical, and turbulent. Each requires some elaboration. First: rapidly. There is no question that the pace of business has accelerated. While many bricks-and-mortar companies don't necessarily have to be first, they can't lag too far behind. There are still great demands on schedule. But, we are learning that if we focus exclusively on schedule, bad things tend to happen as quality is sacrificed. Agile projects are teaching us that the right focus points are customer value and quality -- within predefined timeboxes. Meeting a schedule with poor quality and unwanted features is hardly a success. Agile projects have changed our views about what is an objective (value, quality) and what is a constraint (time). The second issue raised by the above definition is size. In the earlier days of agile development, smaller projects were the norm. Today, companies are tackling all sizes of projects -- even the very large with hundreds of people -- with agile concepts and practices. The third issue is research-like. Research projects are characterized by risk and uncertainty -- risk relating to things that you anticipate might go wrong and uncertainty relating to things that might go wrong that you don't even know about. Research requires exploration rather than a fixed plan. Research is synonymous, at least for our purposes, with innovation, and innovation today is focused on the top line of business: the revenue line. Innovation has become the hot topic in business in 2006 and this focus should continue. Agility is one key to achieving high levels of innovation. The final issue in the above definition is turbulence, which causes projects to acquire research-like characteristics. For example, SOA concepts and technology are emerging, there are many competing vendors, and experience in doing SOA projects is limited. SOA may change business models -- or maybe new business models will change SOA. Web 2.0 may be the next wave of Internet-based business models or it may just be a technology that suffers for lack of a problem to solve. There is one TV commercial in which a store morphs from one business to another in moments as one business model succeeds another in real time. Turbulence, and change caused by that turbulence, continues to be a major factor in business in this decade. High speed, high quality, and high change -- with a dollop of uncertainty thrown in -- define a type of project that agile project management addresses well. These projects may be similar in some ways to traditional projects, but they require more innovation than optimization, more discipline than formality, and more adaptability than control. The fundamental business environment that produced the need for agile project management five years ago is as valid today as it was then. -- Jim Highsmith, Director, Agile Project Management Practice |
"Despite all the data warehousing efforts, BI technology advancements, and the deepening expertise and experience of the BI community, the fact remains that many difficult challenges stand between the business objective and the actionable outcome." Ken Collier
Profundice sobre Agile Project Management a través del Seminario Taller Agile Project Management: Innovation In Action presentado por el Dr. Ken Collier, Consultor Senior de Cutter Consortium. 30 de Agosto Monterrey, N.L., 31 de agosto, México, D.F.
|
APPLYING AGILE PRACTICES TO DATA WAREHOUSING Traditional data warehouse projects follow a typical waterfall development model in which rigorous efforts are made to collect complete requirements, design comprehensive architectures and data models, develop and populate repositories, and, ultimately, develop the analytical reports and artifacts that users want. These projects are complex affairs, involving various stakeholders. Depending on their magnitude, these projects generally run at least six months and can easily exceed US $1 million. But often, despite the best efforts of developers, project managers, and stakeholders, projects run over budget and past deadline, and business users are less than ecstatic about the first data warehouse production rollout. For many data warehousing project failures, the root cause is the disconnect between user and developer expectations. Our experience suggests that an agile data warehousing (ADW) approach greatly increases the likelihood of successful implementation of a data warehouse on time and within budget. ADW meshes well with existing data warehousing architectures and practices. The following practices have proved most effective: Practice 1: frequent, short iterations. Each iteration produces a working and demonstrable data warehouse. Although the length of iterations varies, the aim is two-week iteration cycles. This time frame is long enough to build something meaningful and to undo mistakes without it being too costly. Frequent and short iterations accomplish several goals: (1) users are directly involved in the development cycle; (2) users and stakeholders can see the real progress of development; and (3) developers can verify that they are on the right track. Practice 2: the conceptual phase. This iteration establishes the entire infrastructure necessary for sustainable agile development. Practice 3: develop features, not functions. Agile development is driven by the completion of customer features rather than functions. The aim is to produce demonstrable features that users can review and evaluate in light of business requirements. Practice 4: develop production-quality features. Production teams should create production-ready features; users will be in a better position to provide valuable feedback. Practice 5: Test-Driven Development (TDD). Requirements determine the tests: as soon as your code passes the test, you have met the requirements related to the test. Practice 6: automated testing. Typical system testing is often handled by a dedicated QA team near the end of the project; this is not well suited to the agile practice of testing during development. An agile automated approach allows for testing each table in the staging database and in the warehouse repository as well as the validation of data in the final reports and models. Practice 7: incremental design. Like testing, design and modeling should be integrated into the agile development iterations. While conceptual design largely occurs during the envision cycle or during iteration zero, ADW practitioners should not shirk the responsibility of detailed design. Practice 8: barely sufficient modeling. While modeling is critical to success, effective and agile modeling requires producing only those models necessary to achieve the intended goal of either understanding or communicating. Agile models should accomplish but not exceed their intended goals. Practice 9: build the right project team. No formalized development process can substitute for the right people; and people are not plug-and-play resources. ADW creates an environment that promotes continuous innovation by satisfying users' requirements. It also promotes system adaptability through the ability to rapidly respond to change and to accommodate future user requirements. In 2002, IEEE Software reported that agile methods demonstrated significant improvements in productivity, cost, and cycle time relative to industry benchmarks. Although informal, initial experiences in ADW appear to support these benefits. By adopting an agile model of early and incremental design and testing, developers can produce high-quality data warehouses and ensure that users' needs are met effectively, that the users' expectations are realistic and appropriate, and that developers can adapt to evolving user requirements. ADW helps deliver the system according to changing requirements, on time and within budget.
|
"We dont seem to have to learn how to take control,an even manipulate, to produce an intended result. But we do struggle to learn how ho work collaboratively - al least organizations where control is deeply imbedded each thead of the fabric"
|
Agile: A Set of Methods and Skills or a Leadership Mindset and Culture? A friend of mine evocatively condemns many development organizations as "team ghettos." Designing a team ghetto is easy: organize developers into teams and organize management into silos over the teams, then watch the predictable inversion layer form between the two environments so that nothing ever gets across whole and unscathed -- not information, not people, and certainly not trust, honesty, and the truth about operations, competition, customers, progress, and results. Fear, uncertainty, and doubt about the other group will rule both environments and when the pain threshold is exceeded you will declare that "whole team thing" an impossible disaster and undo it. IT appears to be in full acceleration toward making the same cruel and expensive mistake with agile. We support an intoxicating habit of treating agility as a truly mesmerizing set of skills and methods (they are, aren't they?) as opposed to an astonishingly effective and high-performing mindset, culture, and approach to leadership. The death march of agile ghettos is upon us, and we are piping and drumming to the beat. We've learned the hard way that you can't successfully "install" agile skills and methods in an essentially nonagile culture where traditional leadership mindsets prevail. But we keep trying. Oh sure, you can successfully run an agile project or two in such an environment as long as you have the sponsorship and leadership to buffer the project and team from the organization's attempts to inoculate itself against invasion by agilists run amuck. In fact, this scenario is playing out right now all over the world (drrruuump, drrrmp, drrrmp!). Agile skills and methods succeed on a project or two, but then the proponents of this success meet numbing resistance as they attempt to expand agile disciplines into other teams. Conclusion? Agile methods and skills are necessary but not nearly sufficient elements for creating the agile enterprise. Instead, we need to be thinking and talking about agile as a leadership mindset and culture (see " The Mindset of an Agile Leader," Cutter IT Journal, Vol. 17, No. 6, and " Responsible Change," Agile Project Management Executive Report, Vol. 6, No. 10) that creates one agile operating context throughout the organization supporting the rapid and effective movement of people, information, trust, honesty, and information about projects, operations, and results. Should you wish to work in an agile enterprise, invest in asking and answering a simple question at the enterprise leadership level: How can we operate as an agile leadership team creating and supporting a culture and operating environment of agility for the entire organization? And then answer it by studying visionary value statements such as the Agile Manifesto (http://agilemanifesto.org/) and the Declaration of Interdependence (www.pmdoi.org/). The Declaration of Interdependence especially is focused on agility as an approach to leadership. Use those value statements to pose straightforward questions like the following: What are our greatest sources of organizational uncertainty, change, or complexity, and how might we be welcoming instead of fearing them? What is the continuous flow of value we are providing to our customers? Are our customers present in our leadership team? How are we actually valuing people, creativity, teams, and innovation? When and what will be in our next leadership team release? What will be the length of iterations for our leadership team? How will our leaders pair on assignments? What questions will we ask in leadership retrospectives as we end each leadership team iteration? I think you'll find that agile isn't just for methods and skills anymore. And it never was. -- Christopher M. Avery, Senior Consultant, Cutter Consortium |
Seminario Taller Agile Project Management: Innovation in Action presentado por el Dr. Ken Collier, Consultor Senior de Cutter Consortium 30 de Agosto Monterrey, N.L., 31 de agosto, México, D.F. Si las compañías han de sobrevivir en esta turbulenta economía, deben reexaminar tanto sus procesos como sus perspectivas con respecto al cambio. Ya no estamos hablando del 15% a 20% de crecimiento imperceptible en el alcance de los proyectos. Todo, es decir, el alcance, los atributos, la tecnología, la arquitectura, etc., todo puede cambiar en el transcurso de unos seis meses. Desgraciadamente, las prácticas más comúnmente usadas en la administración de proyectos no ofrecen las herramientas necesarias para hacer frente al cambio continuo. Esta sesión de Administración Ágil de Proyectos (APM) le ayudará a determinar cuando aplicar APM en lugar de la administración de proyectos tradicional. Aprenderá por qué un enfoque bien pensado para la APM puede ayudarle a incrementar la innovación, mantener baja inversión y recortar su ciclo de desarrollo de productos al mismo tiempo que usted sigue respetando las restricciones internas y externas del proyecto.
|
"Los equipos de proyectos de TI que aceptan el cambio y se adaptan respondiendo rápidamente a las fluctuantes necesidades de los usuarios, proveen la infraestructura cultural que se necesita para maximizar la innovación” Ken Collier |
To update your e-mail address with Cutter Consortium, reply to this message with your old and new address. Or phone (52) (55)53360418.
If you do not wish to receive this email newsletter, please reply to this message with the Subject "Remove". (Si no resulta de su interés recibir este Newsletter responda a este correo con el tema "Remover".)
Did a colleague forward this Advisor to you? Sign up for your own free 4 week trial.
Cutter Consortium | 37 Broadway, Suite 1, Arlington, MA 02474, USA. | Tel: +1 781 648 8700 | Fax: 781 648 1950 | www.cutter.com
Latin America Office: Retorno 30 Nº 2, Col. Avante Coyoacan México,D.F. C.P. 04460 Tel: (55)53360418 www.cutter.com.mx