Prediction for next decade (2018-2027) - 2018

1. Agile transformation market will thrive while large enterprises will struggle to transform.

2.  Bigdata trend will keep gaining strength in both spheres – Batch & Real time. But too many tools may kill momentum.

3. SAAS and PAAS will prevail for the small and big enterprise.

4. IAAS will thrive in enterprise data centers (Private Cloud).

5. Industry-specific cloud platforms will rise to cater regulatory and vertical-specific needs.

6. Artificial intelligence will be new playground of software developers.

7.  Digital currencies will impact financial markets in a big way.

8.  Fragmentation of Internet - There will be walls around a country or region-specific internet.

9. Applications will be pervasive in devices and appliances like phones (mobile and fixed line), TVs, automobiles, refrigerators, disk (CD/DVD/BlueRay) players, and any other computing device.

10. Indian IT workforce will shift from permanent job to contractual jobs like in the USA.

11. 3D printing will start making penetration into consumer market which will take a heavy toll on mass manufacturing based economies.

12. Fragmentation and Alternatives of Java and Enterprise Java (like Apache harmony, and Spring) will emerge stronger and official Java from Oracle will lose its sheen due to lust for its monetization by Oracle.

13.  The rise of China-based technology companies.

Top Trends of 2018

1. In software development and maintenance, fall of the waterfall will continue while Agile will be rising.
2. Agile transformation business will flourish further.
3. Agile at scale will continue to haunt.
4. The noise around budgeting, HR, sales & marketing, and other enterprise functions in the Agile adopting environment may become loud enough.
5. Containerization and micro service will keep on rising in software architecture and design.
6. The cloud-based application will penetrate further into the enterprise market.
7. Voice-based interaction and user interface will gain a further foothold in home improvement market.
8. Mobile payment will become ubiquitous.
9. Internet of things will keep growing in consumer and enterprise market.
10. Bigdata, Artificial intelligence, and user experience professionals will be in great demand.
11. Autonomous vehicle technology will be pursued further.
12. Virtual and augmented reality will start making a further inroad into enterprise training business.
13. The merger of devices will continue.

Post Agile

Recently, during an Agile meetup, I came across an interesting question - What is after Agile? This intriguing question did not leave me all day. I explored the internet but was not able to come up with anything concrete.  Agile is one of the steps in the evolution of our working style and heavily influenced by the very nature of the work. Then today, I thought, I should pen down my thoughts.

Before the industrial revolution, we were doing most of our work as craftsmanship which required a heavy dose of interpersonal relationship, col-location, rich communication, and solving unique problems every time.  The industrial revolution brought the division of labor, mechanization, and scientific management which diminished human relationships, rich communication, and problem-solving in a day to day repetitive work environment.

At present, software development is in pre-industrial revolution era where every problem is unique. Though some of us tried to utilize learnings from post-industrial revolution work culture in software development due to a unique proposition of software development, it failed repeatedly. In software development, most of the problems faced are unique, so they require unique solutions. This paradigm forces us to look into pre-industrial era work style which is very similar to Agile way of working.

I visualize at least two possible scenarios which may arise in software development area.

Scenario 1: We develop machines which can solve the problems posed by software development. The software development may turn into something like assembly line operation with the arrival of intelligent machines. Artificial Intelligence, machine learning, and general purpose components are trying to move software development in this direction.

Scenario 2: We keep on solving existing challenges using software and in this pursuit keep on discovering newer challenges. This will keep Agile or its successor alive provided we do not discover a way to replace human intellect by the machine.

So, which scenario may play out in the future? If I have to bet, I will go with the second scenario in short to medium term (approx. 30 to 50 years) and then to the first scenario. As we are discovering better and better AI algorithms in the area of assisted learning, sooner or later we are bound to discover non-assisted AI algorithm (probably using assisted AI algorithms). At that time Agile or not Agile may lose the relevance.

Why there is so much resistance for Agile?

I meet a lot of people who are opposed to Agile. This used to annoy me and I used to think of them as ignorant or snobs. But when I started thinking deeper and kept myself in their shoes, I realized they have their version of reality which makes perfect sense from their position.

 

In my view, this hostility (or apathy in some cases) exists on three different levels:

(a) End result sought

(b) When to use Agile based frameworks/methodologies  

(b) A lacuna in the current approach to various Agile-compliant frameworks and methodologies.

 

Let's consider an example from the business world. Different businesses have different objectives - one may run for profit maximization while other may seek sustainable profit optimization with a healthy workforce. Can Agile be used in both scenarios? Maybe not. In a given context we need to understand what is the expected end result of a way of working - Valuable outcome, sustainable pace, immediate gratification, or something else.

 

As Cynefin framework has defined five decision making contexts - simple, complicated, complex, chaotic, and disorder. Most of us try to stick to the Agile way of working in all five which essentially ruins the Agile way of working. Agile fits well in Complex context and maybe a working solution in Complicated. For Simple context, Agile is over do while for Chaotic context Agile is certainly not a way to go. For Disorder context as Cynefin framework recommend - try to contextualize in remaining four.

 

While talking about Agile, we invariably focus on utopia - no difference between employees & contractors, co-located teams, flat organizational structure, and much more. But in reality, this state doesn't  exist. Most of the frameworks and methodologies claiming to be Agile are mute about:

 

1. Distributed teams

2. Outsourcing partners

3. Expertise based silos

4. Contractual obligations

5. All team members are not expert or skilled. There are Yodas as well as Padawans

6. Even emergent architecture requires upfront thoughts

7. Divide in onsite and offshore

8. Divide among full-timers and contractors

9. Resistance to breaking away from existing organizational pyramid

10. The existence of the project

11. Usage of Agile to squeeze more out of IT and Engineering teams instead of focusing on optimizing effectiveness

12. Marketing of various non-Agile frameworks, methodologies, processes, practices, tools, and techniques by various very successful people and organizations

13. Ignoring existence of various other functions beyond IT and Engineering

14. Silence on individual performance. We are not the only a team but love our individuality too.

 

Should we abandon Agile? Certainly not. Agile is evolving and I expect that in near future, it will tackle the questions beyond today's narrow scope.

 

All this big talk is fine, but what should I do in the meantime?

 

As an Agilist, I prefer to address the underlying causes rather than any specific framework. Also, anything which questions the establishment is bound to face resistance.

 

I hope, this small write up will raise more questions which will help all of us to think little deeper.

How to eat an ELEPHANT?

How lucky I am, I just hunted down an elephant!! I am going to enjoy it for a long time. No need to hunt for a year. I have more than enough food.

Wait!! Meat will spoil soon, so I can not wait for a year to consume even, not six months. What should I do?? Hmm... I have an idea, I will be eating more and finish this elephant in six months.  No way, I do not want to die as obese. Oh my God!! what are my options? Yep, I have an idea, let's call my friends and share the elephant. That's a good idea, when they have an elephant, they will call me for the feast.

Hurray!!! I know how to each elephant again and again.

Now I know, how I will be helping an organization to transform. After all, I know how to eat an elephant.

**Sarcasm** An Agile practitioner is a job killer **Sarcasm**

An Agile practitioner is a job killer

    1. He is multi skilled, he is a job killer.
    2. He produces bug-free code, kills jobs for testers.
    3. He keeps automating repetitive tasks, kills jobs for juniors.
    4. He speaks to customers regularly, he kills jobs for business analysts.
    5. He is part of self-organized teams, he kills jobs for managers.
    6. He shares information freely, he kills jobs for trainers.
    7. He codes, design, and architect, he kills jobs of paper architects.
    8. He is a team player, he kills jobs in HR management.
    9. He is part of collocated teams, he kills jobs in the travel industry.
    10. He communicates all the time with remote team mates, again he kills jobs in the travel industry.

Agile practitioners are job killers, we want our waterfall grown-ups back. We do not want disaster teens, we need grown-ups.

Is Agile a Value System or Belief System?

Yesterday, I had a realization; a bar is a good place to engage in philosophical discussions with friends. To add spice to it is Google. We, few friends, were arguing - "Is Agile a Value System or Belief System". Keeping the sprint of engineering alive we agreed to settle on a definition of value system, belief system, value, and belief.

Value System:  A coherent set of values adopted and/or evolved by a person, organization, or society as a standard to guide its behavior in preferences in all situations. - http://www.businessdictionary.com/definition/value-system.html

Value system:  the system of established values, norms, or goals existing in a society - https://www.merriam-webster.com/dictionary/value%20system

Value: One's judgment of what is important in life, a person's standard behavior or principles

Belief and Belief system: A belief is something in which you believe without supporting facts. A collection of such belief around a context is a belief system.

In some cases, values and value system are backed by verifiable facts or folk lore, myths and legends (not verifiable because concerning events happened in distant past so blurry stories are embedded in society's collective memory or facts and belief manufactured to further an agenda purposefully or unknowingly).

For example believing in the (or many or none) God and associated factors is a belief system but accepting that we do not have any proof of existence or non-existence of God is a fact.

Now, is Agile a belief system or value system?

Certainly, Agile is not a belief system also not a value system but it promotes a value system. The real question is - are values promoted by Agile based on facts (empirical evidence) or manufactured facts and beliefs?

We need more many visits to the bar to explore further :-).

Scrum Rules

Scrum is a process framework/methodology

Scrum requires Agile mindset 

A Scrum team consists of a Scrum Master, a Product Owner, and Developers (members of the DevTeam)

Every Sprint is of same duration

Every Sprint is four weeks or less in duration

There are no breaks between two Sprints

The intention of every Sprint is “Potentially Shippable” deliverable

All meetings/ceremonies are time boxed

Every Sprint starts with Sprint Planning Meeting

The Sprint Planning Meeting facilitated by Scrum Master

The Sprint Planning Meeting is attended by Scrum Master, Product Owner, DevTeam members, and stakeholders

The Sprint Planning Meeting produces committed Sprint Backlog

In Sprint Backlog, the Product Owner defines Sprint Vision

The Sprint Planning Meeting has two parts.

The Sprint Planning Meeting is Timeboxed to two hours / week of Sprint duration

In Sprint Planning Meeting part one, Product Owner offers INVESTable PBIs to DevTeam and encourage them to commit for the current Sprint 

In Sprint Planning Meeting part one, Product Owner and DevTeam negotiate the scope of Sprint commitment 

In Sprint Planning Meeting part two, DevTeam break down contents of Sprint Backlog into SMART tasks

No additional stories to be added into Sprint Backlog after the Sprint Planning Meeting

No story deleted after the Sprint Planning Meeting from Sprint Backlog

Every day of team has Daily Standup at same time of day

The Daily Standup is not a status meeting but information sharing and asking for help meeting

The Daily Scrum is timeboxed to 15 minutes

In a Daily Standup, all team members remain stand up.

In the Daily Standup, every team member answers three questions only. No discussions.

All members of the team attend daily standup

If required after Daily Standup, team members may break into smaller groups

The Acceptance meeting is not an official meeting in the Scrum Guide.

The Acceptance meeting does not have time box or cadence. It is an impromptu meeting.

In an Acceptance meeting, one or more Developers and Product Owner meet.

Developer/s present a story and requests Product Owner to accept it as per criteria defined in Acceptance Criteria of this story.

Developer/s presents stories which have met Definition of Done (DoD).

The Product Owner may accept a story or decline the request

If story is accepted, it is marked as Done Done

If a story is not accepted, it remains in Sprint Backlog and DevTeam continue its effort on the story till it is accepted by the Product Owner in current Sprint or it goes back in Product Backlog for refinement after current Sprint is over.

The Sprint Review Meeting is conducted at last day of Sprint before Demo and Retrospective

The Sprint Review Meeting is for stakeholder feedback on the increment of current increment as well as product

The Sprint Review Meeting is facilitated by Scrum Master

All members of the team attend the Sprint Review Meeting

The Sprint Review Meeting may result in PBIs and/or items to be discussed in Retrospective

The Sprint Review Meeting is time boxed into two hours per week of Sprint duration

The Demo is not an official meeting in the Scrum Guide but most of the teams do it separate from the Sprint Review Meeting

The DevTeam demonstrates (show and tell) the delivery of current sprint to stakeholders

The Product Owner makes a call - Which PBIs to be demo-ed

The Demo may result in PBIs and/or items to be discussed in Retrospective

All stakeholders are invited to attend the Demo

Every Sprint includes Sprint Retrospective for the team to inspect and adapt

The team decides what to be leaked beyond four walls of the Retrospective meeting room.

Follow the Prime Directive of Retro

A Retrospective is strictly for the team. Only pigs are allowed, no chickens

In the Retrospective loop back the action items of previous Retrospectives

In the Retrospective conversation centered around three questions

All team members attend every Retrospective

Scrum Master is not a master of team but Scrum

No one reports to Scrum Master

A Scrum Master facilitates ceremonies

A Scrum Master is a Servant Leader

A Scrum Master works with only one Scrum Team

A Scrum Master is full-time role

The Scrum Master enforces time boxes for Scrum ceremonies and Sprint

A Scrum Master shields the team from interruptions

A Scrum Master is empowered to facilitate to tackle intra-team impediments

A Scrum Master is expected to work diligently to tackle organizational impediments

The Scrum Master has accountability to create and maintain the team’s Sprint burn down chart

The Scrum Master coaches the team to enhance effectiveness

The Scrum Master encourages the team to enhance efficiency and productivity by automation and better engineering practices

A Scrum Master continuously works with team to reflect

A Scrum Master has final authority within the team on the correct way to use the Scrum framework

A Scrum Master does not get involved in technical matters

The Product Owner owns Product Backlog

The Product Owner is accountable to keep healthy Product Backlog

All work to the team routed through the Product Manager

A team has only one Product Owner

No one in the team report to the Product Owner

The Product Owner is the go to person about product vision, goal, and functionality

The Product Owner accepts PBIs through out the Sprint

The Product Owner can cancel a Sprint midway

The Product Owner is always available to the team

The Product Owner keep on providing details on the PBIs as sought by devTeam

The Product Owner assigns business value to PBIs

The Product Owner interacts with DevTeam and stakeholders to keep Product Backlog DEEP enough to DIVE

The Product Owner has system analyst and business domain like expertise to understand pragmatic technological and functional realization of the product vision and goals

The Product Owner represents team in Demo

The Product Owner is accountable to refine Product Backlog on continuous basis

The Product owner do not add or delete items in Sprint Backlog in middle of a Sprint

The Product Owner owns Release burn down chart

In a DevTeam there is only one role - Developer

The DevTeam size is between 5 to 7 people

The DevTeam members are in continuous conversation with each other beyond Scrum ceremonies

The DevTeam estimates PBIs

The DevTeam strives to keep Technical Debt minimal and stable

The DevTeam commits in Sprint Planning keeping in mind the historical facts and current factors

The DevTeam is responsible to potentially shippable increment at the end of each Sprint

The DevTeam keep Product Owner in loop with respect to Technical PBIs

The DevTeam strives for automation in every aspect of development and maintenance

A DevTeam member can describe product with end to end functionality

A DevTeam member can describe product's high-level architecture

A DevTeam member actively seek to help of the team mates

A DevTeam member commits to do whatever it takes to reach each and every Sprint goal

A DevTeam member volunteer for a new task from the Sprint backlog as soon as it completes the current in hand

A DevTeam member is willing to learn any skill needed to help team

A DevTeam member work with all the team members to expand the Definition of Done

A DevTeam member seek direction for product vision and scope from the Product Owner

A DevTeam member never direct any other individual team member which task to work on next

Product Backlog is a ranked list of PBIs

Any one in the universe can add PBI to a Product Backlog but Product Owner prioritize

Product Backlog is an evolving list

Product Backlog is accessible to everyone

Sprint Backlog is a subset of Product Backlog to signify commitment of team for the current Sprint

Contents of Sprint Backlog are suggested by Product Owner but finalized by DevTeam

The order of delivery of items from Sprint Backlog is discretion of DevTeam

In the end of a Sprint, Sprint Backlog should be empty

Sprint Backlog is accessible to everyone

PBI is one which adds value to the Sprint deliverable directly

PBIs keep on evolving with rapid bursts when in Product Backlog but once in Sprint Backlog, evolution is much controlled

Most of the time PBIs are written as user stories

Each PBI has acceptance criteria 

The top PBIs are small enough (effort) that several can fit into a single Sprint

PBIs are invitations to conversations, not detailed specifications

Defects/bugs are PBIs

Scrum Board has four columns - Product Backlog, Sprint Backlog, Doing, and Done

Scrum Board is visual representation of work - To Be, Doing, and Done

Scrum Board helps to visualize and enforce WIP limit

Burn down chart is a graphical representation of remaining work in the current Sprint

Burn up chart is a graphical representation of completed work in the current Sprint

Burn up/down chart is updated daily

PBIs are 3Cs and INVESTable because of SMART tasks to make Product Backlog DEEP enough to DIVE