Project management in agile Smart projects

Projects that are run using the agile methodology Smart are split up into short iterations. There are a different types of iterations defined in Smart. These are Propose, Scope, Realize, Finalize and Manage, guiding a project from the first proposal to application management.

Each of these iteration types follow a straightforward iteration cycle: plan the activities (Plan), perform the activities (Build), and evaluate on the activities (Evaluate). Although the iterations and iteration types all confirm to this cycle, the emphasis is different. Each of the different types of iterations proposes different activities to the list of activities to execute.

Project management activities in the different iteration types

When it comes to project management, each of the different iteration types in Smart propose a number of activities. Whether or not these are executes during an iteration depends entirely on the prioritization during an iterations Plan workshop.


Proposed project management activities will include the following:

  • Propose iterations are targeted at defining a project proposal, or as it is called in Prince2, a project brief. Therefore, the stakeholders and goals of the project are examined, the smart use cases are identified, a first estimate is created and a business case formulated. Each Propose iteration ends with a clear go/no-go decision on project continuation. In most projects there will be only one Propose iteration.
  • Scope iterations dive a bit deeper and aim at delivering the final project proposal, describing all key elements for project management, such as required time, cost, resources, and communication. To this means, we investigate possibly reusable services, the required software architecture, domain models, and possibly a glossary.

    Also in most projects a communication and test plan are authored, and the project plan is delivered. Again a clear go/no-go deicdes on the execution of the project. In most projects there will be only one or two Scope iterations.

  • During Realize iterations, the project team delivers a number of selected smart use cases, the function unit of work in Smart projects. As agile projects go, again priorities are set during the Plan workshop, where the customer, project management and the team involved plan the upcoming iteration.

    On a daily basis short stand-up meetings, set up by project management, monitor the daily work. In a distributed scenario, or in larger projects, several stand-up meetings are run simultaneously, followed by a brief round-up stand up meeting with team leads. Progress is monitored per activity (in most cases smart use cases). Team members report work done using an agile dashboard, and include reporting the estimated time to complete (ETC). This allows for real-time project progress tracking and control. Anomalies are reported immediately.

    Normally on a weekly basis, project management reports to the customer. Progress reports are distilled from the agile dashboard. However, if so desired, customers can also inquire the online agile dashboards.
    At the end of each Realize iteration, the project is evaluated during a workshop, and the approach is tuned, whenever necessary. Also, project metrics are distilled and applied to re-evaluate estimations and project planning.

  • Finalize iterations are executed very similar to Realize iterations. The also are targeted at delivering functionality, stated in smart use cases, and to this means run the exact same cycle as Realize iterations do. However, there is one crucial difference. Finalise iterations are used to round up the project, and there do not allow new requirements any more, but rather finish the last smart use cases still in the list (or back log). Most projects either have zero, one or at worst a few of these iteration.
  • After the project has delivered, the rest of the lifecycle of the delivered application is managed during Manage iteration. Manage iterations also follow the iteration cycle, although the length of such iterations is usually longer, for instance four to six weeks. Bugs, changed requirements and new features drive the iterations, and are prioritized during the Plan workshops.

7 thoughts on “Project management in agile Smart projects

  1. How exactly is this agile? To me this just seems like waterfall with all the project phases renamed to iterations.
    When the customer can’t have working code at the end of an iteration it’s not an interation in the agile sense. It seems the only feedback you get here is metrics from dashboards. Those don’t give you feedback if you’re really building what the customer wants.

  2. Dear Mendelt,

    To my knowledge – but hey, I only have been doing agile projects for the past 10-12 years – I don’t recall that iterations aren’t agile if there’s no working code at the end of it.

    And rest assured there’s lots of feedback in early iterations in Smart projects, e.g. from modeling smart use cases (not: detailing them out, which takes place when they are built during Realize and Finalize iteration). It’s just that, like you say, you will need to know that you’re really building what the customer wants. Where a lot of agile projects do make up a list of stories, features or (smart) use cases, not all agile processes make you aware of these activities, Smart actually does, and so does FDD for that matter.

  3. Agile doesn’t really tell what’s agile and what’s not although “Working software over comprehensive documentation” is a big hint in this case.

    As far as I understand the whole idea of iterations is that instead of dividing a project in phases where you complete requirements, design, implementation and deployment one after another, you devide a project in iterations where you actually do all those things for a small part of the project in every iteration.

    Lean agile learns us that this while it seems wasteful to have lots of small phases it actually reduces waste by reducing handoffs, reducing rework and not preparing work that’s not needed.

    Of course you can cheat. (Scrum does by having separate Deployment iterations) but if you cheat too much you get right back to where we started, big, monolithic waterfall. So if I can rephrase my question to be a little less argumentative 🙂 It seems to me you cheat too by having different iterations. How much do you actually cheat and what are the trade offs?

  4. Since when is common sense regarded as cheating ? The real world seems to get lost a little bit in a lot of the agilists minds.
    The agile manifesto is powerful in its message, and can put a lot of common sense back into the projects where the actual work has lost the focus.
    But please do not act like no preparation is ever necessary for a project, or that the customer never wants to have at least some understanding of what’s going to be delivered at the end of the project.
    I think giving iterations a focus can help doing the right things at the right time in the project, whilst not giving up any of the beautiful advantages that agile software development can give us.

    Regards, Paul

  5. Are you talking about common sense or reflexes?

    Of course the customer wants to have understanding of whats going to be delivered. Thats why you should give him WORKING SOFTWARE AS OFTEN AS POSSIBLE, not just at the end of the project.

    And of course you should prepare. But preparing too much for uncertain situations is is wasteful. Planning is one of the most useful things you can do in a project but pushing all the planning to the beginning of the project is one of the worst things you can do. This forces you to jump to conclusions and take decisions at a time when have very little information to base them on. If planning takes several iterations at the start of the project then you’re planning too much based on too little information.

    Plan just enough, then act on the plan, then deliver the result (working software) to the customer. This is the only way you can really verify the plan/design/requirement was actually worth anything. Planning too much and letting the customer verify the plan (functional design etc.) instead of the result won’t give you much usable feedback.

    Getting customer feedback on documentation instead of working software usually doens’t work In my experience customers will usually sign off functional designs, use cases etc without really knowing what they mean. This will secure you your paycheck at the end of the project but it will not do anything to guarantee that you’re actually building what the customer needs.

  6. Why do I feel like you’re not responding to my statements ?
    Everything you say I believe to be very true, lovely isn’t it.
    It doesn’t invalidate anything I’m writing though, your plee is for something I complete believe and endorse 100% of the time.
    I just think after the (bolted on afterwards) Sprint 0 from Scrum and the “no BDUF” from XP, ADP has an elegant solution to deal with the facts of life, instead of ignoring them.

Comments are closed.