Issues with "Story Point" estimates in the era of agile transformation

Over the past years as companies and organisations take up agile transformation initiatives, the challenge of estimating work has taken multiple turns around "Story Points".

My understanding of the concept of story point is about a number that reflects the "size" of the work being estimated. This simple understanding become difficult to comprehend in collaborative work environments, where numbers mean different things to different Peoples/stakeholders.

The number may quantify "the complexity" of the work to be done, but that raises the question/issue of "what is complexity and how should it be measured/quantified". It may as well quantify the time required to complete the work, but that depends on the resources that will in the end do the work. On another note, it may quantify the volume of work to be done, but again, how should the volume of the work to be done be measured/quantified?

The above aspects add to the issues of correlating the size of work to the required resources to do the work as well as the cost of doing the work. These issues may be difficult to address in an agile transformation initiative. Especially when the perspectives and view points are constantly changing within and across stakeholders.

In my humble opinion, guiding rules and principles on how to derive and interpret "Story Points" within the agile transformation initiative/program must be communicated clearly to avoid irrelevant comparisons of quasi arbitrary numbers that mean different things to different people/stakeholders.

Understanding Role Specifications

Over the years there has been lots of discussions to clear up the confusion around various roles in IT and Software environment. A typical discussion revolved around the question: "Are you looking for an Architect or are you looking for a developer?"

In one such discussion we spent over an hour exchanging various viewpoints and I promised to consolidate some few points in a blog.

1.       Roles are not synonymous to persons. While a person can execute multiple roles, it should be clear what is being specified. An individual may execute the roles of software/IT programmer, engineer, developer, full-stack developer, designer and architect. In the industry you may hear or read of "Generalising Specialists" or "Specialising Generalists".

2.       There are some fine boundaries between roles. The finesse of the boundaries may not be clear to a novice, but with a developed expertise, these boundaries become clearer. For example, writing a computer programme (i.e. Expressing some instructions in a programming language, which is essential to the role of a programmer) has a fine boundary to engineering the sequence in which a set of instructions should be executed by a software (i.e. the essentials of software engineering). In a similar fine thinking, engineering a software has a fine boundary to describing the multiple facets of the software before or after implementation (i.e. the essentials of architecting a software).

3.       Specified roles are good indicators revealing some insights to the collaborative environment. For example, when the specified role gets engineering and architecting mixed up, then you should watch out for an environment where "Generalising Specialists" or "Specialising Generalists" are being solicited.

Developing a comprehensive understanding of the blockchain technologies

For the last three years the number of people asking me about developing a comprehensive understanding of the blockchain technologies have increased exponentially. While in 2015 I had some few requests from collaborators developing Smart Dubai, by 2017 I could count at least twenty conversations a month that related to understanding blockchain technologies. By 2018 I was constantly being bombarded with questions relating to cryptography, stochastics, smart contracts, distributed computing and storage as well as consensus …

When I returned from the future blockchain summit I compiled a list of resources to facilitate a comprehensive understanding of what is today commonly termed Blockchain.

Developing Architectures for IoTx (Internet of Things)

The architecture development process from the sensors gathering data to the data being aggregated and analysed to generating insights and actions, while taking issues such as security and performance into consideration involves a careful understanding of the technology and application landscape.

To bootstrap the establishment of systematically architecting cyber physical systems I developed a table mapping concepts, technologies standards ... (more)

Understanding agile in the Agile Industry

In some polemic talks the focus on the adjective agile in opposition to the noun Agile highlights a deviation of the current state of the trade from the historic intention of putting out a manifestation for agile software development. The deviation could be observed on the agilemanifesto.org website. The url is agilemanifesto.org, the title of the page is Manifesto for Agile Software Development and on the history page it is stated "… What emerged was the Agile ‘Software Development’ Manifesto …".

While the industry evolving around the manifestation is constantly growing, the spirit (Art, Science and recipes) underlying the manifestation seems to be marginalised. That spirit needs to be revived and kept omnipresent across all spheres of the industry.

It is important to understand the manifestation and how it came into being, whenever one talks about agile software development. This understanding is vital in educing the necessary courage required to repeatedly apply the common sense of Plan, Do, Check & Improve in a seemingly complex, critical and regulated environment.

Resources:

1. Manifesto for Agile Software Development: http://agilemanifesto.org/
2. About the Manifesto and its Authors: http://agilemanifesto.org/history.html and http://agilemanifesto.org/authors.html
3. Crystal: https://en.wikipedia.org/wiki/Alistair_Cockburn
4. DAD: http://www.disciplinedagiledelivery.com/
5. DSDM: https://www.agilebusiness.org/
6. Extreme Programming (XP): https://en.wikipedia.org/wiki/Extreme_programming
7. LeSS: https://less.works/
8. SAFe: http://www.scaledagileframework.com/
9. Scrum: https://www.scrumalliance.org/
10. Plan, Do, Check & Improve: https://en.wikipedia.org/wiki/PDCA

 

Synthesising system development methods and not gearing up for schizophrenia

There are various systems development methods and concepts that address some issues within the complex environment of "Systems of Systems". Think of DevOps, Scrum, XP, Kanban, RAD, DAD, ... When faced with the challenge of developing a system under time, budget/money and people constraints, it surely is common sense to tailor a method that fits your challenge. This is generally done by synthesising concepts from existing methods.

If the synthesis is well thought, a development and operations environment is created that harmonises people, tools, processes and other resources. Otherwise the environment gears up for schizophrenia. Environments gearing up for schizophrenia are common place with symptoms such as "people with overloaded concurring roles", "Information overload & reload", "multiple inconsistent information communicated over multiple communication channels" ...

Contrary to schizophrenic environments, desired harmonious environments are created by carefully mapping and sourcing people, tools, processes, accessories and other resources within the given constraints. In such harmonious environments collaborators have an overview perspective from where they can zoom in and out of details to facilitate consistent and coherent communication. A key challenge in these environments is to sustainably maintain information consistency and coherency. This can safely be addressed with SAFe in a healthy mature and experienced manner (bringing the right people together).

Getting the right people, processes and tools at the right place and time is easily said than done. The discipline, time, money, knowledge and attitude required will not be available at all times. And in the context of continuous improvement, this reality is responsible for some skewed decisions screwing up various enterprises.

There is no silver bullet to address these challenges. Every team will have to forge its own bullet and hope it is well formed to assure the development and protection of the desired environment.

Fitting "Cloud Computing" and "Internet of Things - IoT" into your Enterprise Architecture

Fundamental to Enterprise Architecture is describing the enterprise landscapes of products, services, information, responsibilities, tools, technologies, processes, methodologies, as well as the transitions within and across these landscapes. Understanding these fundamentals from the perspectives of Ontology and Methodology, raised the question of fitting cloud computing and IoT into one's Enterprise Architecture. This question is inevitable albeit the current slow uptake of these "new" ways of processing information.

The difficulty in responding to the question becomes obvious vis-a-vis the various organisational scopes and constellations of enterprise architecture practices. In some enterprises architecture is explicit only from a business capability perspective. In others, it is exclusively practiced within the IT function/department. In some rare cases one may find an enterprise with an explicit architecture practice covering the entire enterprise landscape mapping clearly its business capabilities to its various functions. The responsibility of corporate wide architecture practice should/must however be taken by the corporate management (IMHO, by the CEO).

Depending on your scope and constellation, you may be limited. In terms of cloud computing you may be limited to the Infrastructure - IaaS, the Platform - PaaS and/or iPaaS, and or the Application - SaaS. In terms of IoT you may be limited to the things that need to be connected (physical and cyber things), the connection (e.g. WiFi, Bluetooth LE, 6LoWPAN and ZigBee), and or the storage/processing of the information flowing between the connected things, which may likely take you to cloud computing.

Addressing the question, irrespective of your organisational scope and constellation, you should fit the primitives into your ontology framework and adapt your methodology framework to incorporate the relevant processes to synthesising the relevant architecture deliverables. The principles, standards and frameworks of enterprise architecture should always be leveraged to stream value.