Everyone is running a race…isn’t it?
| Students, Grades/marks, learning, knowledge, peer pressure, Wisdom, Success… | Ego, Power, Money, Plan, strategize, Win-Lose, Team work… | IT Corporates, Delivery, Milestone, Sprints, on-time on-budget quality delivery, Competency, Attrition |
Everyone is running a race and each one has specific objective. At high level, is it fair to say this is what the IT Corporates are primarily involved into?
- IT giants who are into product development keep releasing new versions, new products with an intent to capture major pie. New features, patches, providing support is the way of life
- IT services companies use various development tools to build & support products, applications for diversified industries with a set timeline, budget and quality.
Offshoring model is mainly inclined towards providing IT Services and there are lot of companies competing with each other to stay on top or even sustain.
You might have heard of following scenarios/challenges/issues:
- Sales team went overboard and did an oversell by accepting terms which is almost impossible to achieve.
- You might be asked to get started with a project which is signed for a fixed price, fixed timeline wherein the requirements are fairly complex and unclear. There is hardly any time for sprint ‘0’ and everyone starts off without seeing the big picture.
- Agile Delivery issues: These days one need not specify to execute the project using agile process, this is more or less the de-facto industry standard.
- Often Client’s assumption wrt Agile is, ‘Changes can be accepted at any point in time and agile process is all about agility’. In fact agile on the other hand is quite process oriented and teams need to be self-organized, self-disciplined and matured to execute x stories in short cycles (2-4 weeks). However most often or not Clients do not want to hear ‘No changes during the sprint’.
- Productivity and Quality issues: Arguments wrt Velocity not been met, Code Quality issues, not meeting the sprint goals, Feature incomplete etc are common complaints that are heard in agile projects.
We know that it does take time to build trust between Client-and-Vendor. Let’s see the above issues in detail and debate on, ‘how we can possibly mitigate some of these risks’.
Sales process – oversell
Nothing wrong with ‘oversell’ as long as major risks are mitigated and assumptions, dependencies are call out. To meet or exceed the target, Sales team will oversell. We all know that, selling is extremely tough especially when you are establishing or trying to expand/grow in comparison with IT giants as competitors. It’s fair to state that Sales still follows traditional (waterfall’ish ways) methods and often commits to certain budget and timelines. What we need to see is, given this situation, how do we mitigate the risks associated with it? Here are some thoughts and I am sure I will hear tons of inputs from you as well.
- Involving process group, SQA function, Delivery teams, respective practice group and using the knowledgebase artifacts during the Presales and Sales process can be quite beneficial. Taking their learning’s and accordingly taking stand during Sales process helps!
- Traditionally, most of us have heard about discovery phase which clears most of the understanding issues. Similarly, in agile, one should opt for Sprint –2 or –1 or Sprint ‘0’ to ensure there is enough clarity wrt understanding the technical requirements and its associated integration touch-points. In these sprints, most of the assumptions and dependencies should be closed and the big picture should be seen by all the team members. You will be involved in long team meetings conducting workshops wherein you will break the Epics into stories, have poker estimates (or T-shirt size estimates), design approach, assign priorities, build POCs, wireframes etc. Once this phase is completed, the sprint deliveries are much smoother.
- I relate this to Agile DSDM approach. In DSDM, the phases gets segregated as ‘Exploration phase’ and ‘delivery phase’. I have seen excellent successes with DSDM approach wherein the ambiguity, unknown areas, dependencies wrt functional and technical requirements gets clarified. Usually lasts around 4-8 weeks. Believe me this is not getting into waterfall model. Lot of work gets done during this phase. You have good overview of integration touch points, technical requirements, high level design or the approach. Small POC’s are tried upon to validate certain assumptions and the team sees the big picture, clear as crystal. Essentially, every team member is able to wear the functional hat, move the ball rolling, team members understand each other, clear definition of DONE gets agreed upon, tools selection, tracking their effort, how they will mitigate the impediments gets sorted. Worth saying that team gets into self-organizing mode. Post this, deliveries in sprint is much easier
- Essentially, Sales team should be aware of calling out Sprint ‘-1’ or ‘0’ as per foreseen risks and requirement clarity. Accordingly giving some levy to include or make changes to contract wrt timeline and cost, post Sprint ‘0’
- Possibly stating that we are presently 70% or 80% confident of achieving the presently described scope (so and so) by this time. Rest can get uncovered during these sprints (-1 or 0) and the unknown variance wrt timeline, scope and cost can be closed. This will be a big first step towards thinking agile.
- ‘Feeding such learning’s data from Sprint ‘0’ back to the Sales team’ is often ignored. Ensuring that Sales team is made aware of the improvement areas is as important as managing delivery challenges.
Will look forward to hear from you on the best practices that is followed or you think is the right approach.
How do we counter the aggressive timelines?
- For every domain or technology stack; there should be some amount of investment for creating and managing frameworks, accelerators, components and generic solutions. You can form a small R&D team to look into this aspect.
- Embedding such R&D team member into the delivery Scrum team can be quite beneficial. This member can be a core techie who can pick domain nuances and focuses on multiple aspects:
- They can keep an eye on code quality, refactoring and bring in optimization.
- On job mentoring, reviewing happens just like extreme pair-programming. Keeping just enough members who are able to add value and avoid waste is better.
- They can generalize use cases and add to their common repository such that these can be reused as per specific product needs in future.
- Ensuring product IP regulations are not broken is a factor to be considered.
This can be an investment that Services companies can apply. You can always think of building ROI ($) model around this. I will leave this topic for readers of this blog to comment.
- One other concern often arises is to get all the resources attached to project into billed position. Client may not see value add in such investments and expects teams to be highly matured to handle quality and refactoring. The initial phase where trust is just getting into shape is quite crucial. Team takes time to mature and continuously improve. When delivery issues strike, the amount of rework effort can be quite humongous. The above suggestion certainly helps. Such investments can be shared and depending upon value-add; billing can be thought of.
- Initiating such strategy and investments can result in lower margins. But eventually you will reap bigger benefits. Even if you can get 10 to 20% of effort reduced due to usage of generic repository; the objective is achieved.
- In one of my project, I felt the need of adding a technical writer; who brought-in loads of value-add to the entire project-portfolio. The case was discussed and when an explanation was provided on ‘how this will add value’; client was more than happy to try this for 3-6 months. The responsibility included understanding the requirement, high level design and working with core Scrum team in understanding the nitty-gritties. The output was an ‘in-progress’ document covering various feature scenarios and its implementation details. This was quite useful in multi-vendor scenario running various Scrum teams.
This article is getting longer than I thought. Hence I am splitting this into 2 parts. The subsequent part which talks about issues that we face around delivery which looks to be associated with ‘Flip side of agile manifesto’. Yes, you heard it right: ‘Flip side’. Hang on and do not miss the second part of this blog. Meanwhile, please feel free to share your thoughts and comments…
Shrinath's Blog 