Kevin Aguanno (Agilepm.com) zet als redacteur in zijn boek Managing Agile Projects (2004) eerst de basis voor een keuze voor een projectmanagement aanpak neer aan de hand van de mate van onzekerheid. Qua gedachtengoed zit hij op dezelfde lijn als Gary Chin’s Agile Project Management: How to Succeed in the Face of Changing Project Requirements en Jim Highsmith‘s Agile Project Management: Creating Innovative Products (2004).
Wanneer kies voor je voor een klassieke projectmanagementaanpak?
- operationele / productielijn-achtige projecten met veel (externe of interne) belanghebbenden, al dan niet in een enkele organisatie.
- projecten voor product- of procesontwikkeling met veel (externe of interne) belanghebbenden.
- projecten voor technologie- of platformontwikkeling met veel externe belanghebbenden.
Wanneer kies je voor een Agile aanpak?
- projecten voor product- of procesontwikkeling met veel (externe of interne) belanghebbenden als alternatief voor een klassieke aanpak. Als het project in één organisatie wordt uitgevoerd is Agile de geëigende aanpak.
- projecten voor technologie- of platformontwikkeling met veel externe belanghebbenden als alternatief voor een klassieke aanpak. Als het project veel interne belanghebbenden kent, of in één organisatie wordt uitgevoerd, is Agile de geëigende aanpak.
De keuze bij toenemende complexiteit in de projectomgeving juist af te zien van Agile, is interessant. Alistair Cockburn onderkent dit ook in zijn Crystal Methods. Als het projectteam groeit, is meer formele inkadering nodig.
Aguanno’s kijk op planning
Wat is het beste moment om te plannen? Wat Aguanno betreft hangt dat er maar van af. Als je de aannames van eXtreme Programming (XP) volgt, zijn de grote voordelen van incrementeel plannen:
- Early delivery of useful software.
- Delivery of functionality based on the value users give to that functionality (business value-driven instead of architecture-or risk-driven).
- Clear, tangible feedback on progress: each increment delivers finished, production-quality functionality.
- Clear and regular feedback on the quality and fit of the software from the users to the development team.
- The ability to adapt the project plan.
- Clear scheduling and predictable delivery.
- The development of the simplest possible system that satisfies the requirements, without any unnecessary adornments and complexity.
De valkuilen in deze benadering zijn:
- By only looking at small pieces (increments) of the software, we may have to do massive rework, which might have been avoided if we analyzed or designed the whole system correctly.
- We might “paint ourselves into a corner;” that is, we can get a system that is incapable of supporting some new requirement.
- We may be unable to add global requirements, such as alternate language support, performance, and security. A typical example is trying to retrofit “security” to an application that was not designed with this requirement in mind.
- We might go slower because we have to restart analysis and design sessions for each increment, instead of doing it once at the start of the project.
Het boek geeft de volgende tips voor planners:
- If your requirements are volatile or incomplete, if the environment changes, or if you wish to be able to anticipate to future events, work incrementally. If the requirements and environment are stable, you can optimize your process by looking at all the requirements upfront.
- If you are not familiar with the domain, or have not built a similar architecture, work incrementally. Use the feedback to design your system and to avoid unnecessary complexity. If you have created many similar systems, you can do more design work up front. Still, you can always use the feedback to keep your system simple.
- If you cannot deliver incrementally, then don’t deliver incrementally. But, even if you cannot deliver incrementally to your final user, you might deliver incrementally to internal users, such as the quality assurance team, or product managers. Even if you cannot do that, deliver incrementally within your team. That way you still get the benefit of early feedback.
- If you know a requirement is going to be more difficult to work on if you only tackle it later, work on it now. This might happen with global properties of software systems like localization, scalability, and security.
- If your team is big, do enough work upfront with a small team so that you can decompose the work on the system on the basis of a reasonable (but not perfect or final) architecture.
Ook relevant zijn de 10 principes voor het opzetten van projecten, verzameld uit literatuur over systeemontwikkeling van de afgelopen decennia :
- Different projects need different methodology trade-offs.
- A little methodology does a lot of good; after that, weight is costly.
- Larger teams need more communication elements.
- Projects dealing with greater potential damage need more validation elements.
- Formality, process, and documentation are not substitutes for discipline, skill, and understanding.
- Interactive, face-to-face communication is the cheapest and fastest channel for exchanging information.
- Increased communication and feedback reduces the need for intermediate work products.
- Concurrent and serial development exchange development costs for speed and flexibility.
- Efficiency is expendable in non-bottleneck activities.
- Sweet spots speed development.
Projectmanagement niet overboord, maar wel aan verandering onderheving
As managers of several successful XP projects, we have found that strong management is absolutely critical to the successful adoption and application of agile methodologies. But we have also discovered a lack of alignment between the methodologies and tools of traditional project management, and those of newer agile methodologies. Traditional management theory assumes that
- Rigid procedures are needed to regulate change
- Hierarchical organizational structures are a means of establishing order
- Increased control results in increased order
- Organizations must be rigid, static hierarchies
- Employees are interchangeable “parts” in the organizational “machine”
- Problems are solved primarily through reductionist task breakdown and allocation
- Projects and risks are adequately predictable to be managed through complex up-front planning
Regardless of the particular methodology, the traditional project manager is often seen as a “taskmaster” who develops and controls the master plan that documents (often in excruciating detail) the tasks, dependencies, and resources required to deliver the end product. Underpinning this mechanistic approach is the assumption that equates individuals to interchangeable, controllable commodities.
The best project managers are not just organizers: they combine business vision, communication skills, soft management skills, and technical savvy with the ability to plan, coordinate, and execute. In essence, they are not just managers, they are leaders. Every project needs a leader. Agile methodologies free the project manager from the drudgery of being a taskmaster thereby enabling the project manager to focus on being a leader.
Specifically, we have begun to build the notion of complex adaptive systems (CAS) into our management assumptions and practices. The theory of CAS has been applied successfully in several areas — economics, life sciences and more recently, to management.
The concepts of CAS led us to the inspiration that like the XP team, project managers also need a set of simple guiding practices that provide a framework within which to manage, rather than a set of rigid instructions. Following these practices, the manager becomes an adaptive leader — setting the direction, establishing the simple, generative rules of the system, and encouraging constant feedback, adaptation, and collaboration. This management framework provides teams implementing agile methodologies with
- An intrinsic ability to deal with change.
- A view of organizations as fluid, adaptive systems composed of intelligent living beings.
- A recognition of the limits of external control in establishing order, and of the role of intelligent control that employs self-organization as a means of establishing order.
- An overall problem solving approach that is humanistic in that
- It regards employees as skilled and valuable stakeholders in the management of a team.
- It relies on the collective ability of autonomous teams as the basic problem solving mechanism.
- It limits up-front planning to a minimum based on an assumption of unpredictability, and instead, lays stress on adaptability to changing conditions.
Een CAS raamwerk voor projectmanagement
- Non-material fields exert force on material objects. → Guiding Vision. Recognizing vision as a non-material field rather than an elusive destination results in vision continuously guiding and influencing behavior in positive ways.
- Autonomous, intelligent agents form the basis of CAS. Interactions between these agents result in self-organization and other emergent phenomena. → Organic Teams. Recognizing individual team members as intelligent, skilled professional agents and placing a value on their autonomy is fundamental to all other practices.
Teamwork and collaboration form the basis for rich interactions and cooperation between team members.- Local, strategic rules support complex, overlaying behavior in a team environment. → Simple Rules. Rules such as XP practices support complex, overlaying team behavior.
- Information is energy that serves as an agent of change and adaptation. → Open Information. Open information is an organizing force that allows teams to adapt and react to changing conditions in the environment.
- Emergent order is a bottom-up manifestation of order, while imposed order is a top-down manifestation. → Light Touch. Intelligent control of teams requires a delicate mix of imposed and emergent order.
- Non-linear dynamic systems are continuously adapting when they reach a state of dynamic equilibrium, termed the edge of chaos. → Adaptive Leadership Visionary leadership implies continuously monitoring, learning, and adapting to the environment.
Related articles
