Why does the business love Agile development?

Agile continues to be the preferred way of delivering business outcomes. Still organizations use waterfall techniques especially to the system of records. But it is agile that is becoming de rigeur for system of innovation and differentiation. Agile’s willingness to fail is the primary reason that endears it to the business.

I have been involved with more and more teams, especially in Europe. There are some very clear observations that are quite evident.

1. The mentality and emotion quotient surrounding a waterfall project team is still based on avoidance of risk. Of course, they do fill up the RAID log as it is commonly known. Documentation trumps up all other requirements.

   

   Agile Model in action

2. A pre-mature optimization happens in the delivery of such waterfall projects. Many factors contribute to it. One is the time lag behind the business requirements and delivery when everything changes around you in a faster manner. Second, the freezing of architecture and design without understanding some of the future-changes start pushing the projects into a tight corner.
3. Integration happens at the last and that’s where new but significant risks start to emerge as the project deals with other adjacencies.
4. Agile embraces risks and that’s what makes it adopt a different approach. The team starts in a humble manner and learn as they progress. Early and constant feedback changes the games.
5. With each sprint / release, integration happens. The product may be incomplete but it is brutally subjected to feedback and criticism. In general, the right behaviour, in agile teams, doesn’t make them nice and avoid negative feedback. The old adage “Silence is golden” doesn’t work.
6. As the teams, in waterfall, are split into smaller units for tighter control and delivery, the risks due to dependencies (known or unknown) rise faster. Michael Nygard says in Architecture without an end state “The problem with dependencies is that you can’t depend on them.”
7. Waterfall assumes the leader is quite capable and prone to enforcing a herd mentality. This works well to avoid a difficult terrain but not when the business is waiting to expand. In agile, the management trusts the teams to find their own way. This is not to was off one’s hands completely. After spending time to help the teams understand the big picture, trust the team to negotiate further. Equipping and empowering culture are important.
8. Recognizing that change is quite frequent, it is better to work on what we know latest instead of applying an artificial freeze. Agile teams remain flexible.
9. Team happiness becomes critical in agile teams. Continue to measure it.
10.  Agile teams indulge in such planning where more minds are put to work. Instead of waiting for someone to solve their problems, they are encouraged to find their own. The team, typically, rises to the challenges and comes with measures.

Not all parts of IT need to become fully agile for the sake of it.  But, the entire IT, as a coherent entity, needs to be agile o rnimble enough to the changing business. Where it makes sense and where IT remains a blocker to realizing business outcomes are those areas that should embrace this culture. 

Finally, a word of caution. Do not brand agile with no-process or free-for-all approach. It is where you lay the stress that becomes different. Projects in agile mode are also supported by quality and rigorous document and associated metrics. Informality should not be confused with indiscipline.

Which agile model is right for you? What are the solution considerations?

Choosing the right type of agile model is of paramount importance. Enterprises are experimenting with Scrum Kanban, XP, Spotify etc. Looking at the user interaction and rate of change as two parameters, we can make use a specific approach. The following diagram gives one such idea.

In the table below, the considerations of application type, type of work, type of team, volatility etc. determine the applicability of different methodology.

Parameter	Description
Application Type	Strategic Maintain Run to Retire PoC
Volatility Type	High, Medium, Low
Work Type	Large/Medium enhancement Maintenance/Small enhancement Migration Large platform based Innovation
Variability Type	Small, Medium, Large
Team Type	Independent Frequent collaboration High collaboration
System Type	Stand-alone/Small Medium complex/Medium dependencies Highly complex/Multi-dependencies

Based on the above, we can construct a table that shows the usage and applicability of various models.

Parameter	Scrum + XP	Scrum	Kanban	Waterfall
Application Type	PoC	Strategic	Maintain Run to Retire	Maintain Run to Retire
Work Type	Innovation Platform	Large/Medium enhancements	Small changes	Maintenance Migration
Team Type	High collaboration Frequent feedback	High collaboration Frequent feedback	Independent	Independent
Volatility Type	High	Medium	Low	Medium/Low
Variability Type	Large	Medium	Small	Medium/Small
System Type	Large/Complex	Medium complex	Small / Stand-alone	Medium complex/Medium dependencies

What are the factors to be considered in designing the solution and commercials?

When working with a customer's IT organization that is in some form of agile, the solutions team need to consider the following factors and ensure their impact on delivery as well as commercials is understood.

Area	Considerations	Impacting
Transition	·           Current level of agile maturity across business units (Each unit can operate in a different level) ·           Current offshoring maturity ·           Usage of distributed agile ·           Consider various scenarios like: o   Waterfall to Agile o   Agile to Agile.	·           Knowledge absorption: Include pair programming and architectural runway (Existing code, hardware components and software functionality that technically enable near term business features) ·           Replication: Sprint based execution ·           Boot camp duration and costs (focus on Agile foundation, Agile Associate, Scaled Agile. behaviour aspect - People mind set, culture ·           open-up and express their view) ·           Include time and effort for doing agile assessment of the in-scope portfolio ·           Onshore ratio ·           Timeline
Steady State	·           Agile maturity of different business units ·           Level of life cycle management and DevOps tools usage ·           Type of full stack engineers required ·           Availability of roles like PO, Agile coach, Scrum master with the customer ·           Time proposed for transformation ·           Quantum of work ·           Current effective tools usage ·           Usage of DevOps ·           Current mapping of resource levels	·           Operating Model ·           Evolution of ToM across time line ·           Squad size ·           Release cycle ·           Onshore ratio across months/years as the customer moves up on the maturity curve ·           Type of resources and their distribution ·           Productivity % resulting from people, process and tools
Commercials	·           Physical Infrastructure ·           Connectivity requirement considering more online interactions / meetings ·           Typical squad size per ODC (there could be many special requirements per squad)	·           # Travels could be more as compared to a traditional model ·           Special infrastructure (meeting rooms, furniture, boards, interactive rooms etc.)  costs ·           Special equipment like monitor (big size, two monitors per person) ·           Additional tools/license ILF (initial License Fee) and RLF (Recurring License Fee) ·           Cost of baselining the resources of the customer and plotting them against standard models like SFIA or Dreyfus model ·           Recruiting costs (cost of running hackathon) ·           Cost of hosting customer periodically ·           Cost of building Academy ·           Cost of configuration/customization of existing tools, frameworks and accelerators ·           Training / Upskilling costs covering the initial training required to make the resources more engagement ready as well as upskilling as they move the Dreyfus cycle. The traditional training materials will not do.

Is digital transformation the panacea?

Every enterprise is in some stage of “Digital transformation” today. The new ones are born digital anyway. But, is transforming the enterprise digitally enough to maintain their competitive advantage? Does this automatically bring the organizations closer to the business? The answer is NO.

Today’s digital world is shaping the way customers, markets and even employees think, write, share ideas, experience the world leading to changed buying behaviour. The options, before the stakeholders, are vast. Customers change their needs fast even building up some en route. How efficiently can the enterprises understand these changes? The key to success is whether they can make use of this digital transformation into delivering “Personalized experiences or realities” on time. An example is the Japanese e-commerce site Zozotown. Its mobile app is paired with Zozosuits to take customer’s body measurements. They can then order individualized clothes online.

Whilst this is on the customer side, what about employees? Employees should become more like “Human + workers” ready to embrace and apply digital technologies to enhance the way they work and deliver products or services.  Both the entire organization and the employees must keep pace with digital maturity. If either one is incompatible, it may pull down the enterprise ability to differentiate.

The markets are no longer fixed or in a single location. They may not even exist today. Welcome to the world of “digital”, “on-demand”, “At the moment” multi-market scenario. Some may last for a while. Others may not. Enterprises must act keeping this in mind. The underlying processes and structure can be monolithic but the entire firm must be nimble and ready to shape-shift in a moment’s notice. For this, the organizations can and should use appropriate AI tools that help predict preferences and changes in the customers’ thinking.

The essence lies in how the enterprises can effectively use the digital technologies to harness the virtual markets simultaneously building “Trust” with customers, employees and business partners.

Skills for shaping the digital enterprise

In the world of digital transformation happening, how do we see the roles emerge? Does the old definition still hold good? Here is a brief view.

Most organization will become “digital” in some way or other. When they change from a monolithic to a digitally agile unit, usually a saviour is recruited and he or she is called CDO (Chief Digital Officer). But things do not end there. Rather it is a start. The entire organization should become digitally nimble. For that, we also need to see how the roles encompass some of these aspects. Mind you, today’s world will not be strict 1-1 mapping. We will find that CHRO and CMRO should work together in incubating labs and the would be their joint KPPs.

CHRO (Chief Human Resources Officer) - Starts with identification of digital gap and engages in acquisition of such talent to fill the gap. Target is for the CHRO to own the “digital experience” and initiate a culture of “incubation labs” that foster and nurture talent closely allied to business as the enterprise becomes digital throughout.

CMRO (Chief Marketing Officer) - Starts with setting up marketing related digital aspects. Target is to own the “digital experience” along with CHRO. All start up labs / eco-systems for building products and experiences should be the mainstay.

What about CTO (Chief Technology Officer)? The vision of CTO means a nice team of geeks who set the enterprise architecture standards for the organization. Of course, the starting point is development of digital architecture. Target will be to own digital product labs.

The all-pervading CIO (Chief Information Officer) will be responsible, initially, for defining and managing digital infrastructure as part of the enabling function of IT. The entire portfolio including the actual digital infrastructure of the organization as well as the target channels of interaction should be governed in the end.

The CDO (Chief Digital Officer) is the digital evangelist at the beginning. He or she should lead the digitalization initatives as well as the incubator labs.

Chief Data Officer is responsible for modelling digital standards and driving data access. All the development of data-driven products and usage of digital to fuel more data and innovation will become de rigueur.

In summary:

1. Culture will change form strict compartmentalization to porous boundaries. Roles and KPPs will impact each other and will require working together not only across functions but also with various service providers and other technology partners.
2. A common set of traits will form the bedrock of digitally nimble organizations. They will include digital thinking and lean principles. The mindset will move from a generalist to digital generalist taking into account the “domain” knowledge specific to the industry.
3. Finally, every one in the new era cannot be a risk avoider. No reward for such a strategy. They will be encouraged to take calculated risk, try out new things rapidly harnessing data from different channels, discard things that do not work out but in the process go towards what is likely to work.