Project managementthe Agile way

About me

• CEO and CTO @ MindMagnet• Dev agency founded in 2005• 30+ developers• Strong focus on Magento and custom PHP solutions• Background of PHP development and PM• Organizer of Meet Magento Romania

MM14PL

Disclaimer

What this presentation is not:

● complete description of the Agile Manifesto● full presentation of Scrum / Kanban framework● the perfect recipe

What this presentation tries to be is:

● brief presentation of Scrum● our implementation of Agile● tips from our experience

MM14PL

The ProjectsEach project is different, but it generally falls in one of the 2 categories:

Development projects Support projects

● a scope of work● has a clear timeline for delivery (weeks)● requires a team assigned full-time● last from a few weeks to a few months● ends with a release

● unpredictable workflow● deadline is always “asap”● requires developers part-time and most of

the times inconsistently● ongoing

Both are profitable, but they require a different approach in management.

MM14PL

Developer PoolsYou will have 2 developer pools:

1. developers on development project2. available developers

A few tips on these pools:

● try to assign support work to the available developers as much as possible● for “most requested” developers, maybe schedule a day in the week they’re available for support work

(keep that day fixed)● when developers finish their development (scrum) project, they go into the available pool● for new development projects, select the adequate developers from the available pool● don’t overbook your resources, or you’ll fail in the support projects

MM14PL

Agile Values

Values (agilemanifesto.org):

● Individuals and interactions over processes and tools● Working software over comprehensive documentation● Customer collaboration over contract negotiation● Responding to change over following a plan

Key principles:

● (#2) Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

● (#3) Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

● (#5) Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

● (#7) Working software is the primary measure of progress.

MM14PL

Scrum Projects

MM14PL

Scrum Projects

Roles

Product Owner ● adds items to backlog

● sets priorities on the product backlog

● the only person who talks to strangers

Scrum Master ● makes sure the framework is respected

● removes obstacles

● identifies and manages conflicts

● empowers team and helps team improve

Development Team ● delivers an increment after each iteration

● owns the sprint backlog and tasks

● ideally 7 (+/- 2), but not more than 12

● self-organising, empowered, generalising specialists

Sponsor (optional) ● empowers the scrum master and or product owner

MM14PL

Scrum Projects

Project Planning & Estimates

Step 1● Receive client requirements● Clarify vision, requirements, goal for delivery● Agree on a ballpark estimate (money and time)

MM14PL

Scrum Projects

Project Planning & EstimatesStep 2: Breakdown into Epics

MM14PL

Scrum Projects

Project Planning & EstimatesStep 3: Breakdown into Stories

MM14PL

Scrum Projects

Project Planning & EstimatesStep 4: Developer breakdown into tasks (only when inside sprint)

MM14PL

Scrum Projects

Definition of doneRule: “Done is Done”Definition of done is defined by the team.

Example: ● a task is done when:

● acceptance criteria is met● code is committed and pushed onto story branch

● a story is done when:● all sub-tasks are done● acceptance criteria is met● code is reviewed and approved● code is merged into dev branch

You might also want to have “Definition of ready”

MM14PL

Scrum Projects

The Sprint

Sprint planning 1At the beginning of the sprint, the product owner presents his goals for the sprint, selects stories from the product backlog he would like completed.

Sprint planning 2The team (with SM, without PO) places points estimates on the stories (doing pocker planning) and commits to a delivery. The team then breaks up the stories into tasks. The result of these 2 meeting is the Sprint Backlog.

Daily stand-upsThe team meets (with SM, without PO) and everybody mentions what they did the day before, what they’ll do today and if they have any blockers.

Sprint review & DemoThe team meets (with SM and PO) and discusses what has been completed this sprint. Then, a demo is done by the team to the client.

Sprint retrospectiveThe team meets (with SM, optionally with PO) and discusses the framework: what went well, what should change. The goal is to increase the velocity.

MM14PL

Scrum Projects

Sprint WorkInside the sprint, use a Kanban board view.

MM14PL

Scrum Projects

Tips

● “done is done”● always have a demo at the end of the sprint● never force the team to commit● never extend the sprint● expose problems (don’t cover up overruns)● have the product owner be inside your company● have the scrum master be one of the developers● respect the framework (hold the meetings)● have developers do their own basic QA

MM14PL

Support Projects

Use a Kanban board, with more statuses.

We use:● To Do (backlog from client)● In Progress (developer pulls)● In Review (client is reviewing)● Pending Deployment● Done (deployed to live)

Define them however the team/project needs it.Set definition of done and definition of ready.

MM14PL

You’ll need an efficient way to:● allow developers to see what support projects have pending tasks they can take on● allow project managers to see what the progress is on the tasks and set priorities

between projects● allow the client to see what the status is for their task (and what the ETA is)

If you’re favorite tool isn’t doing it, you can try a classic KanBan Board.

Support Projects

Centralised View

MM14PL

Support Projects

Tips

● “done is done”● promise deadlines you can keep● never un-assign developers from scrum projects● check the definition of ready on a task right when you

receive it (working credentials, required resources, etc.)● try to use available developers as much as possible

MM14PL

Developer Empowerment

Advantages of agile for developers:

● requires the whole team to understand the client● makes the whole team responsible (good and bad)● creates a flat structure and encourages collaboration● gives the developers a feel of empowerment (they make

decisions, not only execute)● creates a self-organised collaborating team● team’s efficiency increases with each sprint

MM14PL

Client Education

Advantages of agile for client:

● shows very quick tangible results in deliveries (not just reports)● allows for scope changes late in the project● allows to calibrate effort based on budget● quickly delivers a usable MVP● develops client’s idea using the team’s know-how● agency is being proactive with client’s needs

MM14PL

Thank you!Email vlad.stanescu@mindmagnetsoftware.comTwitter @vladstanescu

www.mindmagnetsoftware.com