10 Sep 2016

Scrum- An excuse

agile

I know it’s a weird topic but when i do retrospection with different scrum teams, i generally face strange excuses. I am trying to recollect some of such excuses from my last few years of experience when i saw Agile overtaking methodical Waterfall approach.

Scope excuses –

  • We (Scrum Team) don’t need requirements well written, cos we are agile. We discover and evolve requirements on the fly.
  • We (Scrum Team) can absorb last minute priority changes as we are Agile in all ways. Please let me do my coding now.

Schedule excuses –

  • We (Scrum Team) don’t need to breakdown our work and then schedule them hard with right identification of dependencies. We just need to know the tasks of tomorrow and that’s it.
  • I (Srcum Team Member) have always understood 1 story-point equivalent to 1 day effort and it’s not my fault if rest of the scrum team have different standard of efforts for the same story-point.

Quality excuses –

  • When i (Scrum Master) have been kind enough to absorb last minute changes by Product Owner, why Product Owner is not kind enough to accept my Product with less quality.
  • I (QA Engineer) always receive Product Release in the last minute of Sprint and then asked to stretch. I am demotivated as most of the time i am not able to run enough quality cycles within given time.
  • I (QA Engineer) am always blamed for not being Agile and resistant to last minute changes

Resource excuses –

  • I (Team Member) am a shared resource and always in trouble in right justification of time on multiple Agile Projects. Each of them have priority of sprint backlog with same degree.
  • I (Scrum Master) don’t do team building/revision until Sprint starts and why should i care about Organization wide resource planning cos i am Agile.

Role excuses –

  • I am Scrum Master of many Projects because i used to play the role of Program Manager and same (bossy) role i want to justify in Scrum Model as well.

Super Duper excuse –

  • Who says we are not Agile, we have been using JIRA for our Project Management and we are also having daily stand ups on top of that. We follow Hybrid approach actually :)

Enough said about excuses. I believe that it’ not just adoption of a smarter Methodology, rather this is change of mindset. In all cases, a great Planning (Scope, Schedule, Resource), Risk Assessment, clarity on roles and responsibilities, alignment with market commitment are still required.

It can be a great factor to make Scrum a successful model if every stakeholder gets trained and certified in this methodology and benefit organization with values rather than burdening with excuses.

Good Luck

vcs

 

blogspicify

We have been running demos of Beta version of Enterprise restaurant solution – SpicyFi (www.spicyfi.com) where we claim to give end to end solution to our customers, i would like to share some of the experiences we got.

  • Right Users:- It’s important to identify right users of the product, so we got not just corporate representative but also the waiters, chefs, attendants, guests and outlet managers as our audiences Honest feedback from the right users is the real reward.
  • Simplification:- Any product should have features simple enough to understand that can create interest in audience to see what’s gonna be next. We should realize that not more than 20% of the features of all great products are used more than 80% of the time.
  • Pain Areas  -> New requirements:- We start with our understanding of pain areas of customer and encourage users to add if they have something else too. With right understanding from user experience and benefit  we add new user stories in Product Backlog.
  • Continuous Improvement:- We don’t claim to be the best product in market but claim to be best committed on the path of continuous improvement.
blogsplunk

Splunk is a unique platform to get the actual disparate systems throw their logs to one common platform where intelligence could be produced for Business, Security and overall health prospective.

When we talk about enterprises, it could be composed of any set of systems, in-house or external, legacy or customized, customer facing or business facing, Microsoft or Open Source etc.

I remember my experience of IT support in retail with World’s 2nd largest Home Improvement where handing Sales on Thanksgiving was a nightmare. Getting experts for 20 different running systems and also from the respective business in a War room had significant budget involved.

Now, when any unwanted error comes at any retail counter of any of over 1700 stores, a panic button is just an inch away. Everybody starts looking in the system, each one of the stakeholder (Hundreds) is being seen as a culprit, separate error logs are being watched and there are dozens of facilitators involved to connect the dots, so that no error stops the smooth sales of Thanksgiving.

This is just an example I used to be part of, but I believe each enterprise faces such situations and does post-mortem too. There must be a wish – can’t we have some Robot to assess all involved systems and just give the indicator of problem long before problem occurs.

Journey continues and an answer comes in the form of Splunk.

  • Why can’t we have each system implement their logging mechanism uniform?
  • Generally, data flowing in the participating system cause that, why not just capture that data in a secured way and point that out?
  • Let’s have an agent in each participating system irrespective of their underlying OS (Linux, MS, Solaris, Mainframe etc.) and job of agent is just to push the logs to a common server.
  • Let Common platform empower the stakeholder to build their dashboards for whatever needs they have, like Information Security, Web Interfaces/System Handshaking, Core Business Purposes or even for Root Cause Analysis.