Showing posts with label waterfall. Show all posts
Showing posts with label waterfall. Show all posts

Monday, March 25, 2013

Is Scrum Master a Project Manager in Agile Scrum?

The straight answer to that would be 'no' - and I guess everyone who has spent 30-40hrs learning Agile Scrum would know this short answer, but let's understand why behind it and that is really important.

OK, lets understand why these two roles are NOT same -
1) Agile teams are self-organizing teams, so if you are PMI Project Management guru (aka PMP) you would know - Project Manager spends lots of time and energy in organizing these resources (developers, testers, analysts etc, and their tasks etc) so by definition, these activities are no more required (to a greater extent), so Scrum Master is not supposed to (and may not even know how to...) do resource management. Scrum Master is like a coach in Scrum Team not manager.

2) Scrum Master (also explained as 'servant-leader' in scrum guides) - is there to do specific job(s) - ensure scrum rules/practices are being followed, remove impediments, (and keep chickens (sounds unfamiliar? - read this) away from team but keep them happy). Project Manager on other hand is assumed to be master of all these - so this is actually similarity between these two roles - but Project Manager is expected to anyways be master of all these (e.g. ensure project management practices are being followed, remove hurdles/blockers, keep chickens happy...), but this role carries lot of other responsibilities as well, than just that.

3) Ever heard of WBS, estimation, gantt charts, critical path analysis? - that's what we don't do in Agile Scrum, but on other hand in waterfall, all these are termed as 'most important tasks for a project manager', and hence a Project Manager is different from Scrum Master. Even estimation is done by developers in consultation with Product Owner, and Scrum Master has little role to play there.

So in nutshell, the role of Project Manager is divided is Agile Scrum, and the tasks are distributed (by nature of Scrum), among all members of Scrum Team.

Further reading - I strongly recommend you to read a short and simple (16 pages) Agile Scrum Guide by Ken Schwaber and Jeff Sutherland.

Wednesday, March 6, 2013

Release Sprint v/s Release v/s Deployment

Lets try to understand these three terms that sound so simillar - Release Sprint, Release and Deployment -

1) Release and Deployment are more or less same. Though these two may have different meanings in some cases - say in waterfall we say 'QA release' and 'Production deployment' - that are two different terms, but in this context these two are same. Once the Sprint Review is over, it 'may be' released/deployed.
At times, 'Release' can also be referred as 'Release Cycle', e.g. a large project can be proken down into mutiple Release Cycles and each may tie back with some organization/business/program objective. In my view, Release (as in Release Cycle) has same meaning in Waterfall and Agile.
2) Release Sprint is actually a special sprint that may take place if release/deployment itself is sizeable effort that is expected to span 2-4 weeks. This type of Sprint is not recommended and should be avoided, as efficient Scrum teams would always finish a functionality that meets 'Definition of Done' and always has a ROI value attached to it so can be released, hence teams are expected to use automated deployments tools to avoid need of such special Sprints.

Sunday, March 3, 2013

Waterfall Manifesto

Take a break from Agile Scrum and here is what I would strongly recommend you all - the Waterfall Manifesto. I assume the authors are serious when they describe this as - "Manifesto for Realistic Software Development"

Read on what author documented in waterfall principals (and they are so practical and true.....!) -
  • Changing requirements are a pain in the ass.....and make him pay dearly for just thinking about change.
  • Business people and developers ......They both have other important activities to carry to waste their precious time in meetings. Furthermore, they do not speak the same language.
  • Build projects around solid processes because you know that individuals are even more unreliable than software
  • Project reports and billable hours are the primary measure of progress.
  • Recognition of technical excellence and good design allows developers to think that they are free creative artists
  • Complexity - the art of maximizing the amount of time needed to understand your design and code - is essential to define your value as a developer ( and to protect your job).
  • At regular intervals, the team should meet to eat pizzas and drink beer. It helps developers to forget that they are working in a bloody software development project and confirms that the management really cares about people
 Reference and credits: www.waterfallmanifesto.org