Agile projecten methodisch aanpakken – Robert K. Wysocki – Effective Project Management

Discipline verwarren met bureaucratie geeft aan dat je efficiënt en effectief zijn hebt vervangen door een focus op het proces. Voor agile projecten, waar op voorhand weinig bekend is over de benodigde oplossing voor het gegeven probleem, zijn verschillende aanpakken voorhanden. Vaak wordt de verkeerde keuze gemaakt, of slaafs de bedrijfsstandaard gevolgd.

In de 6e editie van Effective Project Management geeft Robert K. Wysocki in hoofdstuk 11 Agile Project Management aan, dat er 2 soorten projectmanagement levenscycli zijn bij agile projecten:

  1. iterative, met IBM Rational Unified Process en Prototyping als bekende aanpakken
  2. adaptive, met Scrum, DSDM Atern en Adaptive Software Development (ASD) als bekende aanpakken. Zelf introduceert Wysocki Adaptive Project Framework (APF)
De auteur benoemt de praktische uitdagingen bij releases van opgeleverde software. Kan de organisatie het tempo van de ontwikkelteams aan? Is elke 2-4 weken vrijgeven van nieuwe software aan focus groepen, of verzamelen en bijvoorbeeld eens per kwartaal of halfjaar uitbrengen van een nieuwe versie de oplossing? Denk aan eisen die de organisatie aan documentatie, training aan eindgebruikers, plus allerhande afhankelijkheden met product- en marktontwikkeling, budgetcycli, reclamecampagnes, etc. stelt. En hoe ga je om met portfoliomanagement of afhankelijkheden tussen projecten (inhoudelijk, bemensing, ophanging in een programma). Het zijn aandachtspunten, waarover je in Scrum of RUP handboeken geen uitspraken zult aantreffen. Het paradigma van een geïsoleerd team, dat zelfsturend zichzelf voorziet van werk en volledig zelfstandig software kan ontwikkelen en implementeren, is een oversimplicatie van de vaak weerbarstiger werkelijkheid.

Opstart-, initiatie- en afsluitingsfase in een agile projectmanagement aanpak

Scope bepaling kan gedeeltelijk. Veel over de oplossing is immers niet bekend. Daarin schuilt wel een grote uitdaging voor belanghebbenden die wel in bijvoorbeeld 2-4 weken opstart- en initiatiefase een ‘compleet’ Project Brief, Project Initiatiedocument (PID), Software Architectuurdocument (SAD), Business Case en set requirements verwachten. Een work breakdown structure (WBS) of product breakdown structure (PBS) is gedeeltelijk op te stellen. Planning is op hoofdlijnen, namelijk die van time boxes.
Je ontwikkelteams moeten wel bemenst worden. De huisregels, wijze van besluitvorming, verdeling van verantwoordelijkheden, risk management, etc. moet wel ingericht worden. Ook bij de projectafsluiting zijn reguliere activiteiten als het compileren van geleerde lessen, verkrijgen van decharge en overdragen van specialisten- en managementdocumentatie aan de orde.

Kenmerken adaptive project management lifecycle

  • Iteratieve  structuur
  • Just-in-time planning
  • Critical mission projects
  • Streven naar verandering via leren en ontdekken
In lijn met het Agile Manifesto zijn sterke punten van zo’n aanpak:
  • Does not waste time on non-value-added work
  • Avoids all management issues processing scope change requests
  • Does not waste time planning uncertainty
  • Provides maximum business value within the given time and cost constraints
Zwakke punten zijn:
  • Must have meaningful client involvement
  • Cannot identify exactly what will be delivered at the end of the project
Voor de projectmanagers die in Scrum zoeken naar zelfbevestiging, waarschuwt de auteur:
In the Scrum Adaptive PMLC model, there is no project manager. The development team is a self-organized team. If you are more comfortable having a named project manager, the closest in a Scrum project is the client. A client is called the Product Owner in a Scrum project. Each Scrum project has a Scrum Master assigned to the project.

Adaptive Project Framework

Kenmerkend voor dit raamwerk zijn de volgende kernwaarden:
  • Client-focused — The phrases “walk in the shoes of the client” and “always do what is right for the client” express what it means to be client-focused.
  • Client-driven — Engage the client in every way that you can. You want them to have significant meaningful involvement, to have the sense that they are determining the direction that the project is taking. Remember, it’s their money, and they have the right to choose how it will be spent. At the extreme, this would mean having the client take on the role and responsibilities of the project manager. This will not happen very often, but you should look for opportunities to make it happen.
  • Incremental results early and often — Deliver a working application to the client as early as possible, especially in cases where the real solution for the client has not yet surfaced despite all best efforts. The functionality of the first iteration of the application may be very limited, but it should deliver business value and give the client an early feel for what the final deliverables will be. Giving the client an opportunity to work with something concrete is always better than asking them to react to some vague concept described in a complex specification document. If you can put something in front of the client early in the project and repeat it often, they get a sense of belonging and ownership — they become engaged in the project.
  • Continuous questioning and introspection — When you build a solution iteratively, you have more chances for creativity and more opportunity to adjust as better and more valuable features or functions are discovered. The client and the project team should always be looking for improvements in the solution or the functionality offered both as the cycle build proceeds and as they look back at previous cycles.
  • Change is progress to a better solution — One of my colleagues is often heard saying: “You’re always smarter tomorrow than you are today.” He is referring to improving estimates over time, but his comment applies to APF as well. APF starts with the client and you agreeing on a definition of what is needed and what will be delivered. Your efforts will be good and in earnest, but remember that all you have done to this point is take the best guess you can as to what will be done.
  • Don’t speculate on the future — Someone once said: “If you don’t know the future, why waste time planning for it?” APF strips out all non-value-added work. Planning is done just in time. It focuses on what is known about the solution, not on what is not known.

APF heeft 5 fasen: Version Scope, Cycle Plan, Cycle Build, Client Checkpoint, and Post-Version Review. Het biedt daarmee meer houvast voor organisaties die in hun projecten adaptief willen werken dan een kale Scrum gids. Ben je benieuwd geworden, schaf dan Effective Project Management aan om je verder te verdiepen.

Enhanced by Zemanta