The way a development team operates has a huge impact on what it achieves. The methodologies used, practices, cross-functionality within the team, and communication styles, all have a definite impact on building the foundations of the team and the successful execution of a project. From estimations, resource management, managing project costs, keeping track of tickets on different boards, encouraging faster and smoother communication, adapting to change requests and everything else that it entails, every development team struggles to keep everything on track. And to be honest, no methodology seems to fit right and at times, we are left to wonder, do these methods actually make an impact? You find yourself busy with making estimations that don't match, reports that are far different from the forecast, you see your team moving tickets without a proper understanding of the end goal of the product, and trying to keep a clear line of communication within the team and with the client. Have you been frantically searching for a method that collects the pros from different methodologies and empowers the team to execute a project faster and better without losing sight of the business aspect of the product? Join and discover.

1. ShapeUp Your
Agility!
GETTING OUT OF THE RABBIT HOLE

2. The Bigger Picture!
No matter which field of expertise it may be, if you look from a higher perspective
the way of running a team and executing any project is the same.

3. The Famous Process!

4. The Scrum
Cycle!

5. Project
Planning
Project Planning
Communicating the product vision,
refining the product backlogs, and
setting priorities.
Team Formations
Resource allocations,
communicating the project
requirements, explaining the
technical depts to the team and
planning the project execution.
Requirement Gathering
Understanding the client's needs
and proposing solutions.

6. The Kickoff !

7. Sprint
Planning Sprint Backlog and Estimations
Selecting the prioritized and refined
product backlogs that align with the
sprint goal. This is normally
presented in board of some variety
and tracks the sprint progress.
Sprint Goals
The commitment of the sprint. What
would be the incremental release?

8. Estimations!
Three-point estimation to planning poker. We have
done it all.
How accurate have you been?

9. The Sprint
Daily Scrum
A pulse check which highlights any challenges
that may obstruct the team’s progress.
Scrum Team
Developers + Scrum master + Product owner.
The drivers of the sprint.

10. Boards, tickets and everything in between!
Every sprint should release an
incremental value to the product.
How are you tracking your progress?

11. Sprint
Review Feedback
Feedback is the key outcome that
would ensure the product is build as
per the product vision.
Demonstration
Demonstrate the product increment
achieved in the sprint to all the
stakeholders.

12. Deployment ready?
The team comes together and deploys the
sprint-long development to demonstrate an
increment.
Does your deployments go as planned?

13. Inspecting the work process to increase quality
and efficiency.
Sprint
Retrospecti
ve

14. Team indulgence?
The team being vocal about the shortcomings
or things they did well.
How interactive are your retrospectives?

15. The Delivery !

16. Looks like a smooth well defined
process for the perfect execution right?
BUT has it ever worked as planned?

17. The Rabbit Holes!

18. 1.Requiremen
ts
They're either too defined or not defined at all.
Either ways the team struggles to extract the
right details.

19. Either the requirements are too detailed
and does not leave room for creativity.
Or too vague that the team fails to
understand the core intent of the
requirements.

20. Can we find a sweet spot in between?

21. A small senior group of people shapes
the work at the right level of abstraction.
Concrete enough that the team knows
what to do, yet abstract enough that they
have room to work out the interesting
details themselves.
Shaping!

22. Fat marker sketches!
Working at the right level of
abstraction with defined "No
Gos" not only ensures the
team moves at the right
speed but also leaves this
important room for creativity
in the later stages.

23. Have your priorities set!
The problem, The appetite, The solution, The
rabbit holes and The no-gos.

24. 2.Estimations
You thought through the details, used the tools to
define velocities, and even involved the team to
estimate the backlog.

25. Sadly, changes and obstacles are
inevitable. The end is not so clear
anymore.
Result?
EXTENSION!

26. How about we reverse the approach to
estimations?

27. Setting an
appetite!
Fixed time, variable scope!
Short enough to see the end goal but
long enough to ship a working
product.
Then, set your appetite for
deliverables based on the fixed time
frame instead of calculating the
estimated time for the listed
requirements.

28. Pitch a rough and bounded
solution with risks addressed

29. Instead of asking how much time it will take to
do some work, ask:
How much time do we want to spend and is this
idea worth it?

30. 3: Team
ownership
When requirements are broken down into
tasks, the team is focused on the tasks
assigned to them only.

31. The team does not feel responsible for
the whole product. Ticket moving
becomes a priority, losing sight of the
actual intent of what they are building.

32. Can we bring back accountability?

33. Trust the team to take on the entire
project and work within the boundaries
that have been shaped.
Allow the team to define their own tasks
and their own approach to the work.
They will have full autonomy and use
their judgement to execute the pitch as
best as they can.
Assign projects,
not tasks!

34. Get one thing done!
Teams can be working on multiple things and get many tasks done, but until there
is that one clickable button with its intended result, the progress of the team will not
be visible.
Lots of things are done but nothing is really done!
Pick one slice of the project to integrate as a whole. When that’s done, the team
has something tangible that they’ve proven they’ve work on.

35. When the teams are not assigned tasks they
understand the bigger need of the project. Hence,
they will themselves discover the needful things to
be done and resist optimization as "changes".

36. 4. Progress
tracking
When processes are given too much
importance the team gets busy maintaining
reports and documents, moving tickets, and ...
losing precious time.

37. How many times have you felt you lost
your day making reports, generating
documents and...
changing it again with every update?

38. What if we simplified the process and
made it more visible?

39. There are always imagined and
discovered tasks.
Projects usually have two phases. The
uphill phase of figuring out what the
approach is and what needs to be
done.
Once all the work involved is clarified,
there’s the downhill phase of
Projects are like
Hills!

40. Hill chart allows everyone in the team to
be on the same page regarding the
project's progress as a whole without the
temptation and focus on moving individual
tickets.

42. 5. Change
requests and
feedback
They are inevitable. You always feel the
urge to do that one extra thing.

43. Everyone wants the best product. You
will always find something to optimize
and once you start these considerations,
it goes on and on and on.
BOOM!the time has slipped away!

44. What if you focused on the trade-offs?

45. By chiseling and hammering the scope,
you stay focused on just the must-have
things to ship something effective.
Testing and coding standards should be
maintained by the team too.
Scope
Hammering!

46. The team takes responsibility for the basic quality
of their work. Developers write their own tests, and
the team works together to ensure the project
does what it should according to what was
shaped.
QA is for the edges!

47. 4. Bugs
All software has bugs and when they are
found it is of the utmost importance.

48. All other work is left aside and the team
is after resolving bugs. The list just
continues. In no time, the focus is shifted
from building a product to
Killing the bug!

49. What if you could focus on the bugs
separately?

50. There is nothing special about bugs! All
software has bugs and there is no need
to drop everything and focus on it till it's
a crisis.
That being said we still want ways to
deal with them. The team can
self-organize a day to pick off the most
important bugs and solve long-standing
issues.
Bug Smash!

51. Have a cool-down period between cycles. This is the
time not only for bug fixes but to allow the team to
breathe and think about what’s next.

52. Wondering if this is a legit
approach?
Besides my personal experience using these methods, are you asking yourself if
there is a core backup to this?

53. There actually is a
framework!

54. Shape Up! by Basecamp

55. My name is Kshitiz.
Project delivery lead at Gurzu Inc.
01
Registered Product Owner and Scrum Master
02
Thank you for listening!
DONT FORGET TO SHAPE UP YOUR
AGILITY!
https://basecamp.com/shapeup https://discourse.learnshapeup.com
Resources