How to know if Agile is right fit for project or not?

One of the common question I am asked is, How do I know if agile is right fit for my project or not?

While there could be multiple factors influencing this decision, here I am reviewing the top 6 points that shall help you make a decision -

1. Team's location - well, while many would debate on this, but it is not that easy to run agile projects if team is spread across multiple locations/sites and in some cases floors. If you are considering "scrum of scrums" scenario, you may have those scrum teams across multiple locations/sites but 'one scrum team" should ideally be co-located.
2. How urgent the changes are - If changes are urgent, frequent, only model that could save you is "agile", so don't look further,, go for it. It is in the core of agile to be able to support business agility.
3. How clear the requirements are - Sort of connects back to the point #2, if the requirements are not clear upfront (well low level), so this would mean that frequent changes, so agile is the model to go for. 
4. Can it be sliced into smaller usable chunks? - Agile demands the work to be broken down into smaller chunks, and each of that chunk should be "usable" some way. If that's not viable, agile might not really fit as you would end up with large chunks of work that would take several days to finish, making it difficult to adapt to frequent changes if need be, and further taking longer to demo or time to release to end user.
5. Access to PO/users - Agile needs access to Product Owner or user quite regularly (actually PO), and if no one person can take charge of it, agile just won't work. You need someone who can write requirement statements (aka user stories), help groom the stories that development team can understand and implement.
6. Process v/s project - repetitive or new endevour? - Of course, go back to the definition of project - is it really a project or a process, if later, head elsewhere, it is not a candidate for agile.

List doesn't end here, but hope this helps get broad idea to start with. Happy to hear your views.

DevOps Basics - Communication & Ownership

I saw this pic on a slide in an online tutorials about DevOps, and it immediately caught my attention, hey! I recognize this!

How common is it to throw the stuff over the wall....but wait! we do take ownership of the 'stuff with us', but probably when done with 'our part', we tend to pass it over without too much of deliberation, or concern, or knowledge about it thereafter.

(image courtesy udacity.com)

...and what if the end user (customer) throws is back too!?...remember when that happened to you last time?...to me that happened just last week.

If I go back few years, I have had stuff thrown over to me and having no clue what to do with it, and how to deal with the situation, task or whatever, and I recall having done this myself (hey unintentional! OK :P), and stuff happens, and the question is - can it be avoided....Yes!, of course.

Communication is the key! To some it comes with ease, while for few others it is just ain't easy. Just like everything else, it takes practice, more practice and little courage and I heard beer works great too :D !

Ownership and a bit of attitude to pick up and fix the stuff! Some of us might think that "ownership" means more actions on oneself, but in my opinion ownership gives you more choices to act, and better control over any situation.

...and Break the silos!...is it same as communication?...well I think it is more about those 'virtual' walls we usually have created, than 'communication;...what say? Silos could exist between two people sitting next to each other, who talk so often. It is like being a bird in 'cage without walls'. Sorry I just over-complicated the definition of silos :P

We all love to get the things done, no one wants to be on team that has customer throwing stuff back at them, is n't it?, but working in silos is just so convenient at times, people just find it easy to 'throw over the wall'.

Enough, I am done! Going back to my next slide...

Scrum Master - Part Time or Full Time? - Answered!

According to my friend Jeff Sutherland, co-creator of Scrum, Scrum Master is a full time role and here is what he stated in his Scrum Handbook - 

Since Scrum makes visible many impediments and threats to the team’s and Product Owner’s effectiveness, it is important to have an engaged ScrumMaster working energetically to help resolve those issues... Scrum teams should have a dedicated full-time ScrumMaster, although a smaller team might have a team member play this role. 

Did you get his point? Read this again and focus on the highlighted text above. 

It is a full time role and job both, probably easy to digest for large teams but most would disagree that this is a full time role for an average size scrum team. Going by Jeff's statement above - in a smaller team (6-8 members) a team member may be playing the role of scrum master. Mind it, even in this case, it is a full time role as this member might be involved in coding-testing activities but he would still be spending good time doing servant leader activities as well - like removing impediments, continuous improvement, ensuring scrum is followed, and so on. In a larger team this role gets to spend more time doing all of that and lot more. 

In my experience I have seen a good mix of the following -

- scrum masters supporting more than one scrum teams - team or project compromised? Most likely yes!

- scrum masters involved in tasks not related to scrum or scrum team - compromised? Yes

So think again if you or any of your teams practice part-time scrum master role. 

What is the best way to resolve conflicts in Agile Scrum teams?

Before we discover the best way to conflict resolution - try to answer these questions -

1. If a team member or some of the team members observe that a particular member is not performing as he/she should who should they talk to about this first? - Product Owner, Scrum Master, Manager or that member?
2. Who should resolve conflicts in scrum teams? - Scrum Master, Product Owner, Manager, or the team?

Answers to the above questions are 1) member, 2) the team. Did you get you questions right? If not, here is explanation -

There is no role called Manager in scrum, so it has to be one of other three parties - since Scrum teams are self-organizing teams so as first step they are expected to talk to the member they have problem with to resolve any possible issues, conflicts. Important part is 'first step' - if this doesn't work, they may take Scrum Master's help and/or may follow organization escalation process.

So the best way to resolve scrum team conflicts is that team shall discuss about issues within themselves and try to resolve it that way.

CSM v/s PSM v/s ACP - explained! - updated on 23rd June 2015

Let's understand few of the leading Agile certifications - CSM (Certified Scrum Master), PSM (Professional Scrum Master), ACP (Agile Ceritified Professional), ICP-APM (ICAgile Certified Professional in Agile Project Management) - in three easy steps -

1) CSM is from www.scrumalliance.org, PSM from www.scrum.org, and ACP is from www.PMI.org (yes, same organization that offers popular PMP certification), ICP is from another independent organization ICAgile (https://icagile.com)

2) CSM can be equated with PSM (Level1) but none of these two can be equated with ACP - first two are Agile Scrum specific certifications, where as ACP and ICP are more extensive and focus on Agile as whole.

3) CSM - get mandatory training (paid) from www.scrumalliance.org and take exam (free) on their website and you are done (I don't know anyone who has ever failed this exam - so kool!), PSM is slightly difficult, no mandatory trainings - pay exam fee online at www.scrum.org and take exam. As you would know from my earlier point, ACP is the most difficult one to earn. You can learn more about ACP at www.pmi.org, to earn ICP you need to attend a mandatory two day training, no exams though, certification is at discretion of trainer (anyone ever denied a certification thus far?).

Final verdict - as an expert myself, i suggest to go for PMI ACP if you really want a certification that industry cares about. A certification doesn't guarantee you a job or any other award, but it surely is a distinction that stands you apart in this crowded professional world. Good luck!

BRD, Requirements Document in Agile Scrum?

While comprehensive documentation is valuable, a working software is MORE valuable as per the Agile Manifesto. One of the myth about Agile Scrum is that it promotes no documentation. The fact is that documentation is certainly not a bad thing, but Agile suggests to create minimum required documentation.

So the question is where do you keep user requirements - trying to find something similar to BRD (Business Requirements Document) in Agile?

The answer is rather simple - "product backlog"! Product backlog is only place to capture all the user requirements and as we know these requirements are prioritized by product owner for each release, sprint and is called release backlog and sprint backlog respectively.

Pic: 1) Product Backlog, 2) Release Backlog, 3) Sprint Backlog

You may also want to check this post to learn more about difference between terms Release, Sprint.

Impediment v/s Bug - are they same or different?

Let's understand what is impediment and bug in Agile Scrum. First of all they both are not same, they may be distantly related in some special situations but they are different.

Here are the basic definitions:
An impediment is a situation that is stopping/blocking the completion of work.
A bug is referred to a defect or issue in the work product.

On side notes do you know that the word "bug" was used to indicate an actual bug (fly, moth) on a circuit board causing a short-circuit or other problems. You can read more details here - http://theinstitute.ieee.org/technology-focus/technology-history/did-you-know-edison-coined-the-term-bug

A defect would typically NOT block the completion of work, though in some situations a defect may impede work and also be am impediment at same time. For same reason, a defect would relate to implementation of a work item (user story), where as impediment would block one or more work items (user stories).

Defect and impediments are tracked seperately in defect tracker and impediment tracker. Bugs would eventually be prioritized and added to product backlog and re-prioritized by product owner. Impediments would never be added to product backlog, but resolution of an impediment may be taken out as spike; if some research work is involved and/or a major bloker to work.

While bugs can be identified during development activities (coding, testing etc), and impediment would typically be identified during daily scrums. The scrum master is responsible for helping resolve these impediments to improve team productivity.

Sprint velocity basis yesterday's weather - Agile (XP)

Ok, before we understand what is 'Yesterday's weather' in Agile, let me tell you that Yesterday's weather is not an agile scrum term but an extreme programming term. Some of Agile terms are used interchangably now a days, and this is one of the methods to estimate sprint velocity for upcoming sprint, so thought to cover this term.

Lets take this example -

if it has been raining yesterday in Delhi, then it's quite likely that it would rain today as well. It may not be 100% accurate forecast but still good enough to suggest someone carry an ambrella today.

In Agile, 'yesterday's weather' refers to last sprint's velocity. Development team may have been working at varying velocity in past sprints (20, 18, 25, 28) so one of the ways to estimate how many story points development team can deliver in next sprint is to check last sprint's velocity - this may not be the best way but can be called a best guess, or bet. So in this case, 28 story points would be the answer.

You may also find these related posts valuable in Sprint Planning section.

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.

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.

Scrum Events Timeboxing

All the events in Scrum are timeboxed and here is the list of key events and their timeboxes -

• Sprint (also called as iteration) - 2 weeks (or as planned - between 2-4 weeks)
• Sprint Planning Meeting - 8 hours*
• Sprint Review - 4 hours*
• Sprint Retrospective - 3 hours*
• Daily Scrum Meeting (also called as Daily Standup) - 15 minutes (fixed regarless of sprint time)

* - time box given here is for a four week (one month) sprint - to be adjusted depending upon the sprint duration.

What Product Owner is busy with during Sprint?

Though Agile Scrum has just three roles - Product Owner, Scrum Master and Developers, but the roles and responsibilites of each one can be very confusing at times. One of the most frequently asked question is "what activities a product owner engage during sprint?"

Answer: When sprint is in progress, Product Owner would usualy be busy grooming prodoct backlog, answering queries from development team (if any), talking to stekholders (dont forget- he is adding new items to product backlog, re-prioritizing items etc....so he needs to talk to stakeholders), and may help with some early testing and provide feedback as well.

Who updates Burndown Chart?

This is very frequently asked question (usually thrown as one of the options)- who updates Burndown Chart? Product Owner, Scrum Master or Developers or any of these?

Answer: The Developer Team (or say Developers).

Explanation: Since burndown chart is all about the 'remaining work' or 'remaining hours' so developer knows how much work is done and how much if left (and remaining work).

Further, Development Team would also be responsible for updating the work estimates during the Sprint - because of same reason as above - they know it best and can revise estimates (e.g. they raise a question to PO and basis inputs from PO they feel that it would take more effort than expected or remaining).

Theme, Epic, Story, Task, Feature

Theme, Epic, Story, and Task are Agile Scrum terms, whereas 'Feature' is a term is not so often found in Scrum handbooks (probably introduced by some eager minds).

1) Theme is logical grouping of stories
2) Epic is just a large/big story - that needs to be broken down in smaller stories
3) Story is a story (explained elsewhere), that is broken down into tasks to be worked upon by developers as per agreed 'definition of done'

In terms of size - Theme and Epic may be of different sizes, rest would always be in this order (from large to small) - Epic > Story > Task
So technically, only these two combinition are possible (just in terms of size as theme and epic are not comparable - if anyone is interested) -
1) Theme > Epic > Story > Task
2) Epic > Theme > Story > Task

Acronyms, Agile and Associations

Acronyms/Mnemonics in Agile and their associations -

Associations - 
DEEP - properties or characteristics of a good product backlog
INVEST - properties or characteristics of a good user story
3 Cs (CCC) - three critical aspects of a user story (or in 'plain english' - one of the many ways to write a user story).

Full forms -
DEEP - Detailed Appropriately, Estimated, Emerging/Emergent, Prioritized
INVEST - Independent, Negotiable, Valuable, Estimable, Small, Testable
3 Cs - Card, Confirmation, Conversation

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

Scrum Team v/s Development Team

Lets understand what are Scrum Team and Development Team in three easy steps -

1) Scrum Team consists of three roles - Product Owner, Scrum Master and Developers
2) Every team member (apart from Scrum Master, Product Owner) in Agile Scrum is called a Developer (regrdless of their skills - tester, analyst, architect, SME, etc etc)
3) Group of Developers is referred to as 'Development Team'

Timeboxing v/s Parkinson’s Law

Lets understand the connection between Timeboxing and Parkinson's law -

1) According to Parkinson’s Law - "work expands so as to fill the time available for its completion". What that really means is that a worker will drag the work to use up all the time given to him/her - even if he/she can finish that work ahead of time. So if a work is estimated to take 100 hrs and a worker has completed 50% of work in 25 hrs, he/she will still consume all 75 hrs to finish remaining 50% of the work.
2) Timeboxing suggests to fix 'time to completion' for the agreed upon Sprint goal and the Sprint will end at fixed time (hence term 'time boxed'), so the developoment team moves together to achieve the Sprint goal within given time period.

Sprint v/s Iteration

Lets understand the difference between Sprint and Iteration in three easy steps -

1) Iteration is a generic Agile term that is used for any process thats iterative/repetative
2) An iteration in Agile Scrum is called a Sprint
3) Other Agile variants may or may not use same term to define iterative work, but these two are most common terms in use

Sprint Zero v/s Spike

Lets understand this in three easy steps -

1) Sprint Zero (also called as Iteration Zero) is not same as Spike. Spike is a 'story' and a Sprint may have one or more stories in it
2) Sprint Zero is usually done/planned/executed to perform some research or initial work that is required beefore you start First Sprint (also called as Sprint One, Iteration One)
3) Any Sprint may have one or more stories (also called as User Stories), so the Sprint Zero may be planned if there is a need of Spike (some research work etc.)