I am open to speaking engagements in SMAC, Agile, and Security. Please get in touch!
Social Media Marketing, Search Engines, Gamification, and Online Branding
Native and Hybrid Mobile App Development, Mobile Testing and Deployment
Web and Mobile Analytics, Data Science/Machine Learning, Statistical Analysis
Scaling Applications, Cloud Security, PaaS/IaaS/SaaS, Containerization
Agile/Lean/XP/Scrum/Kanban/SAFe, Corporate Agile Transition, DevOps with Ansible/Vagrant/Docker
Hadoop/Spark/Storm/Flink, Machine Learning with Mahout/MLib/SkyMind
Designing Reactive Applications, Back-Pressure, Akka Actors/Streaming
Functional Programming with Scala, Riak, Redis, Cassandra, SOLR, Python, R, ACT/Play Framework
In Scrum and similar Agile product development methodologies, backlog prioritization is one of the principal duties of the Product Owner and determines the order in which product features are developed and ultimately delivered. Despite its obvious significance, current methods of backlog prioritization suffer from one or more of the following shortcomings: failure to elevate risk to the same level of consideration as business value, measurement of business value using metrics that are not as useful or even available at the start of a project, and sub-optimal ordering of backlog features. Although backlog prioritization is the responsibility of the Product Owner, it is nonetheless a collaborative effort. As such, the demands of the business should be balanced against the concerns of the development team. The predominant approach to measuring business value is via a priori financial metrics (NPV, ROI, IRR) or market research (Kano analysis). It is simpler and just as credible and accurate to use a relative business value to rank features and defer financial analyses until after the first release, when the results of sales and customer feedback are actually known. When sorting backlog items, much of the Scrum literature either prescribes a consensus approach (Delphi method) or pairwise comparison (bubble sort). I present an alternative approach that formulates the problem as an iterated 0-1 Multi-Objective Knapsack Problem (MOKP). By incorporating risk as a separate objective and making use of readily obtainable input parameters such as relative business value, this approach addresses the shortcomings cited above. I propose exact, heuristic, stochastic, and approximation methods to find optimal or near optimal solutions for the MOKP with reasonable computational effort for one or more teams assigned to a single product backlog.
As an Agile transformation consultant, I regularly come across organisations that, despite their alacrity to transform team effectiveness, are often mired in a host of entrenched beliefs and habits that threaten to derail any concerted effort to effect positive change. Indeed, before any Agile transformation can take place, it’s important that organisations assess their readiness from a cultural and behavioural perspective in as honest and transparent manner as possible. In this article, I’ll discuss just two of these pernicious habits and how organisations can overcome them effectively.
I am available to author articles/books or offer my opinion on digital transformation topics.
Copyright © 2017 Tarun Sukhani