This talk given at MeetMagento Poland 2014 presents my experience with doing Agile development and its challenges on development vs support projects. It will be a practical approach to project management, with how Agile can be applied inside a modern web development agency. Talk covers resource assignment, Scrum, Kanban, developer empowerment and continuous delivery with client satisfaction.

1. Project
management
the Agile way

2. 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

3. 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

4. The Projects
Each 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

5. Developer Pools
You will have 2 developer pools:
1. developers on development project
2. 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

6. 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

7. Scrum Projects
MM14PL

8. 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

9. 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

10. Scrum Projects
Project Planning & Estimates
Step 2: Breakdown into Epics
MM14PL

11. Scrum Projects
Project Planning & Estimates
Step 3: Breakdown into Stories
MM14PL

12. Scrum Projects
Project Planning & Estimates
Step 4: Developer breakdown into tasks (only when inside sprint)
MM14PL

13. Scrum Projects
Definition of done
Rule: “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

14. Scrum Projects
The Sprint
Sprint planning 1
At 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 2
The 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-ups
The 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 & Demo
The 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 retrospective
The 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

15. Scrum Projects
Sprint Work
Inside the sprint, use a Kanban board view.
MM14PL

16. 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

17. 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

18. Support Projects
Centralised View
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.
MM14PL

19. 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

20. 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

21. 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

22. Thank you!
Email vlad.stanescu@mindmagnetsoftware.com
Twitter@vladstanescu
www.mindmagnetsoftware.com