(In this SmartBits, Sudhir Patnaik outlines “ Extreme ownership mindset “. The video is at the end of this blog)
There is a tremendous shift towards a customer backed approach. Everything that we do is keeping our customers in mind and an extreme mindset of product ownership. The one scrum team mindset is driving phenomenal change in how we deliver products. This is where extreme ownership mindset comes into picture where a scrum team owns outcome for customer. The days are gone, when one has to develop, somebody else has to test and somebody else has to deploy. It has to be packaged in such a way that as a member of the scrum team every single member of the scrum team owns every single responsibility. If I am a developer or a test engineer, I own development, I own testing, I own deployment, I own support. That’s the team’s extreme ownership. That’s a disruptor.
(In this SmartBits, Zulfikar Deen outlines “Business mindset“. The video is at the end of this blog)
As a partner/solution provider, the first and foremost one is the need to have a partnership mind with the IT team of organization. It is about understanding the difficulties that have been articulated, spending a few of days with them in meetings and understanding the process and difficulties and empathise with the team.The solution needs to be planned right from the technology, to rolling out, to support along with the organization. Hence taking a partnership approach is of utmost priority.
Secondly the solution needs to be cognizant of the
whole life cycle of system, be it a patch upgrade,
support or training. Everything has to be taken into consideration for the
solution to be successfully used by the user, the whole chasm needs to be cast.
As a solution provider one must try to keep building these layers or parts of
the system and have a view of whole thing into the solution, as it gets much
easier then to roll it out.
Thirdly, never attempt to do a half-baked solution of production roll out, it is going to be very very challenging.
For instance if there are twelve thousand users one cannot control the
perception of users. Once the user gets the perception that the system is not
good, it is very difficult to recover
from there.
If we have to deliver a minimum viable product of
three features, we need to do it thoroughly well, make sure it is integrated
well and works well before we put it into the system. One should never have the view of handing
over the system tousers, get feedback and then figure out what to do with them. A very
different counter view of the DevOps process has been considered in this case.
Finally, always build in a bake-in adoption matrix, people don’t do that normally. If a system is rolled out, the management, CIO, or even we as a solution provider should be able to look at the adoption matrix as a business matrix, where in actual adoption, usage, everything has to be already baked. These are the views beyond technology, database or architecture and need to be part of one’s thought process and view when building a solution.
When we are actually working with the solution providers who are not large but small, there is always a thought about the risk of startup going down. Then what happens? How do we protect our business is always on our mind and we should never underestimate that thought process. The best way forward as much as possible is to build on open standards, open platforms. When we use open source , it gives a sense of comfort. If something goes wrong we will be able to find skills to manage this beyond. Otherwise we are already challenged with team that is not able to scale up with the rapidly moving technology. We can’t take one more solution and figure out what happens with the system. So it’s easier sell for a solution provider who build on open standards and take it to the market Open standards could be domain specific for example with healthcare it could be HL7. It could be technology specific. It could be domain, technology or either one of them build on open standards, making it easier for us to make the right decision.
