Skip to main content

The enterprise agile

Consumer Vs Enterprise

Every time there is a consumer use product, we see that the enterprise comes up with a very customized version so that the enterprise does not have to adapt. This is with good reason.

Enterprise is an entity that is too complex and having it to change would mean a disruption to the business  - something that the stakeholders are not very happy about.

For example, take the iPhone and Blackberry. iPhone is a consumer centric product while Blackberry is a very enterprise centric product. However, iPhone introduced major disruptions to the way the enterprise security functions and forced enterprises to be more flexible with the way they allow employees to view email. This increased productivity since employees could view their emails at home or anywhere on the move and respond more quickly.

Another example is Microsoft word Vs Google docs. The days when a simple document would have to go through multiple revisions with the whole track changes turned on and that enormous document is a day of the past. Google disrupted the way people collaborated on documentation with people being able to collaborate more openly and cutting down the turn around time.

Business Disruption

Both the examples caused major disruption to the business. It was fraught with dangers of security and hacking - in this every open world where every one is paranoid of leaving the day open to hackers. However, the benefits out weighed the risks

Business disruption has always been weighed in terms of the benefits vs risks. There has always been a inherent pessimism in taking up anything that is disruptive to the business - especially with new technologies - that do not seem to have a direct correlation to the nature of the business.

Software Delivery

Almost all the enterprises - irrespective of the nature of the business - have come to view software delivery as a major contributor to being relevant and being a driver in their respective fields.

The transition from the traditional form of software delivery to agile has been very rough. Being an area where research has just started on its contribution to the industry, all enterprises tend to view any changes to the traditional software delivery process with skepticism. With very few case studies out there on the success of agile in enterprise, most of the enterprise entities are only ready to pilot them and transition to enterprise agile slowly.



Scaled Agile Framework (SAFe)

Scaled agile framework (SAFe) has been a very good candidate in terms of making enterprises comfortable in terms of software process. 

SAFe is a really good adaptation of agile processes to the enterprise without compromising on any of the agile principles. It also does a very good job at making sure that the enterprise is able to relate to the whole process by keeping the terminology to the minimum.

However, it is SAFe’s packaging - that endeared it to the enterprise - that is going to be its downfall as well.

SAFe is packaged very similar to IBM’s Rational Unified process. It is got very clear process flows, actors and description. It is very lucid in terms of the details that needs to be fleshed out at what level.

What it lacks is the same level of support that IBM offered to back up RUP. SAFe is being implemented by tons of vendors in multiple enterprises and each of them sell it in their own way. So SAFe does not have a standard implementation. The process does not have a good offline enterprise support once the consultants exit a SAFe implementation at an enterprise.

One of the implementations that I saw had omitted the entire concept of Business Value - which is blasphemy in the agile world. While SAFe does mention about business value, the vagueness in its offline documentation and the lack of offline support meant that the enterprise has got it wrong.

Lean Project Management Office

Contrast that to the lean PMO -Lean Project Management Office.

The whole concept of a Lean PMO concept is to start with the simplest process and mature it as we move along and have more learnings. It gets customized for the enterprise by the enterprise themselves. Some of the key concepts of a lean PMO - Business value based prioritization, Level the workload, Pull based project intake process - helps in resource optimization and business value enhancement. 

The central theme of the lean PMO - reducing water & subordination to the bottleneck - guides the PMO is making choices and is not process driven. While this aspect of the lean PMO does not endear itself to the enterprise, it works a lot better and more efficiently over a period of time 



Scaled Agile Framework Vs Lean PMO


With the entries entities having to make a choice between SAFe vs Lean PMO, most of the enterprise entities go with SAFe because of the following approach
  • SAFe looks more familiar than lean PMO
  • Lean PMO introduces change more constantly than SAFe which is just a one time change. Enterprise entities do not like change that often
  • Lean PMO needs more mature people with specialized skill to be successful. It is not that SAFe does not need them, it is just that Lean PMO needs these people through out since it is about constant process improvement.


Conclusion


Enterprise entities looking at adapting agile in their software delivery process will look at going ahead with SAFe for now. However, Lean PMO would start playing a bigger part at a later point of time when the lean way of thinking in the software delivery process becomes more mainstream thinking and less of a specialized skill .Till then, it is going to be SAFe.

We do hope that SAFe handles all its challenges - of having better consulting partners and better offline support  - as its implementation across communities grow and a more vibrant SAFe community comes up.

This is also available on slideshare: http://www.slideshare.net/npm123/enterprise-agile-42978609



Comments

Popular posts from this blog

My Journey in Inquiry and Advocacy - An experience report

It is recently that I have consciously started practicing Inquiry. Let me explain. I am a consultant who constantly looks at the situation and comes up and implements the solution to progress from there. While I do that, I constantly use Inquiry as a means to progress - one of the key facilitation technique specifically in multiple stakeholder situations.

Principles for developing systems that are anti-fragile

I have been trying to make sense of what anti-fragility means and how do I use that in my day job. As a Business Principal, I tend to work with the abstract but orchestrate a program of work that needs details. This makes my job a little difficult in the terms of designing for more self-preserving systems that preserve the spirit of the abstracted strategy or vision. I came across an article from Daniel Russo on anti-fragility and his attempt at creating a manifesto similar to the manifesto for agile software development. For more reading on Daniel Russo, here is his profile:  http://djrusso.github.io More reading from his paper here:  https://www.sciencedirect.com/science/article/pii/S1877050916302290 This post is an attempt for me to understand what goes into developing a program that uses every opportunity to strengthen itself and achieve its objective - the vision.  I liked the approach of principles for developing systems that are anti-fragile. It is a very valua

User Personas

User Personas are a very good tool for the product owners, business analysts or product managers to be able to co-create with designers. It is predominantly a product of the user research and should not be an amalgamation of demographic data. It is the best way for us to list all scenarios that a persona would take when they want to attain a goal. It is predominantly used to build empathy with user, focus the team and build consensus in a large diverse stakeholder group. The website I referred to is here:  https://www.smashingmagazine.com/2014/08/a-closer-look-at-personas-part-1/