Application of ‘Theory U’ in agile transitions

Right now I am in the middle of a consulting assignment of transitioning a large team from ‘scrum but’ to right scrum. When I say right scrum, I refer to the scrum guide by Ken Schwaber and Jeff Sutherland which can be downloaded from

This team from a very large multi national product company came with the baggage of ‘I know scrum, and now you teach me scrum’ attitude, because they have been practising some sort of scrum. This attitude is not something new for me, as I have come across similar situations before as well.

Since agile is value based, like religions, a loss in faith is very difficult to be restored. No amount of talking would have convinced them. This is the biggest risk/challenge while dealing with teams with partial knowledge of s rum. At least that  is my judgment, based on my past experiences with teams with partial knowledge of scrum.

As a coincidence, this was the time I came across the theory ‘U’ which was advocating the postponement of the three fears of;

Fear of judgment
Fear of cynicism
Fear of change

for effective change management.

I decided to implement the concept of ‘postponement of these fears’ at every stakeholder level, me being the first one. All the coaching sessions started with the request to postpone these fears till the completion of the first sprint, and the results are very positive. After experiencing the right scrum, most of these fears are automatically addressed. So, make it explicit to postpone the fears of judgment, cynicism and change before implementing will give you a smooth start.


Are your stories ready CXO?

What is it that you really want?, and when will you say that it is done?. These are two fundamental prerequisites before delegating work to someone and this becomes the real cornerstone for success in the outsourcing world. Identifying the right features and having clarity on them is the foundation for delivering value to your business and to get the best out of your outsourcing partner quickly, thus maximising the ROI. Agile frameworks, especially the product backlog, user stories, value stream mapping and release planning are great opportunities for maximising the ROI and to ensure the alignment of your IT strategy to the organizational strategy. Agile frameworks provide great opportunities to the CXOs and their business analysts to maximise value, if they embrace agility before identifying the vendors, so that agility can be enforced from the contracting stage itself. Are you listening?.

Posted from WordPress for Android

Risk driven contract selection for agile projects

Which contract type to use for agile projects?.

This is being discussed everywhere without a firm conclusion. Recently I came across this again in a linkedin group where they discuss about agile and lean. Agile advocates true partnership with the client. During my past ten years of entrepreneurial experience, wherever we signed a contract or MOU, things did not work out well, because the trust element was lacking. Everything was seen from the angle of contractual terms and conditions. Business relationships which really thrived were based on trust and a win-win spirit. You get lot of benefits of of this and please share part of it with me attitude really worked well.

In a project scenario, ideally the product owner come from the customer’s side. In an outsourced environment this may not be feasible, hence we operate with the help of proxy product owners. The proxy product owner or the product owner is the representative of the customer, and is part of the integral agile process. It is not about just making profit to the supplier, but about delivering maximum value to the customer.

In the traditional waterfall, we had the following contract types; fixed price, cost reimbursable, time&material and purchase order. Whether we follow agile or waterfall, these contract types are applicable. The criteria to choose the contract types must be the clarity of requirements than agile Vs waterfall. For projects where product backlog and key user stories are clear, and the technology is also well known, then fixed price is still valid. If the requirements clarity is not very high then the next best option is Cost reimbursable. If the requirements clarity is totally lacking the T&M. If we are in a long term business partnership with a client then the best suitable contract type for agile is ‘Cost + Benefit share’, where the cost is reimbursed to the supplier during the development phase and a percentage of the returns on investment (ROI) is also shared with the supplier for a pre-determined period.

So, the options are many. What need to change is the shift in focus from the profitability of the supplier to value to customer, and eating a piece of the cake as well. Contract types are just a vehicle of smooth delivery of value, and must be decided based on functional and technical risks at hand.

Three questions to analyse the agility of the teams

Many claim that they have implemented agile, and very few have good implementations of agile. In order to understand the type of implementation one has, these three questions to help;

  • What is the velocity of the last sprint?
  • Do you have work allocation or work volunteering?
  • Can I see your sprint burn down chart?

What is the velocity of the last sprint?

Velocity is the productivity figure of the previous sprint, generally counted in story points. In order to calculate the story points, one need to have user stories, planning meeting and planning poker in place. In a sprint, the team is supposed to commit to the velocity (story points achieved in the previous sprint). The team may achieve slightly more, if their capability is better, and that becomes the basis for estimate for the next sprint. This is the continuous productivity improvement mechanism. If the team members do not know the velocity of the previous sprint, then I must say that it is a serious symptom of faking agility.

Do you have work allocation or work volunteering?

Agile teams are self organizing. The team has to decide how they are going to do the work. In true agile teams, it has to be work volunteering, not work allocation.

If the team has velocity calculations in place, and is thriving on work volunteering, then I respect their agility. They are doing things correctly, where as others are just claiming that they are agile.

Can I see the sprint burn down chart?

A burn down chart is more like a flight landing within the runway. Without it there is no transparency into the process and inspection based on empiricism is lacking. If the team is using the burn down chart to track their progress every day and make decisions based on it, that is a great positive sign of a good implementation.

If a team is doing very positively on the above three questions, then they have a respectable agile implementation. Others are just talking about it.

About the author of this post

Abrachan Pudussery (Aby) is a freelance agile coach, working closely with teams in improving their agility. He lives in Kochi and Bangalore cities of India. Phone 0091 9895372115 email : 

10 key reasons to be truly agile – by an Agile coach, witness

  1. Faster return on investment (ROI) to the customer through iterative and incremental deliveries, than the traditional big bang deliveries. This gives an opportunity to the customers to start using the key features early.
  2. Better transparency to the customer – The customer gets absolute visibility into the development process. In account where we were associated with agile roll out, their customer was asking their supplier (my customer) to recruit more people, because of the better transparency into the manpower loading pattern and the work to be completed.
  3. Better risk management (financial, technical, people) –  The risks could be both positive and negative.  In one large team I got associated with, they built a product for three years to realize that nobody wanted it. A fast failure would have helped them to save millions. That was the reason why they embraced agile. A fast failure of a sprint due to architectural issues will always help to avoid lot of rework. Early sprint failures due to technical deficit of the team stops the development of a substandard product. Is it not good. If you appreciate it, you have the right agile mindset.
  4. Better predictability – In agile planning, the target set for a sprint is always based on the historical data of the team’s productivity. This increases the probability of the teams delivering what is committed, and very often little more than committed.
  5. Better transparency to the development team – In one organization the development head was highly skeptical about scrum initially, because he felt he is going to loose visibility into the development process. Luckily he sat through the agile training along with the team and towards the end he became the biggest supporter for agile. After understanding the agile framework, he realized that the transparency is much better than the traditional models.
  6. Better productivity by eliminating non contributing members– Yes, I meant productivity. Not from day one. If we go to the gym, first we get body pain, then only the benefits follow. Same is the case here. When we embrace agility, initially it hurts, especially the non contributing members to the deliverable. They can either become contributing members, or they do not have a role in the agile world. That is a reality one has to face. Over a period of time (not years, I am talking about a couple of months), you will have a team of contributing members only.
  7. Better productivity through positive peer pressure – One of the key aspects of agile teams is their self organizing nature. The decides how they are going to operate. It thrives on work volunteering than allocation. This brings in better ownership and productivity.
  8. Better work life balance – Agile talks about 8 hour working days. We are not talking about spending 8 hours in the office. We are talking about doing 8 hours productive work in the office within 8 – 9 office hours. This leads to better motivation and energy levels.
  9. Sense of urgency – Every sprint end is more like a project end. The pressure is always on the team. This speeds up work. When we conducted a survey for a team of 100, after experiencing scrum for almost 10 months, they unanimously said that they are under pressure with pleasure. It is a constant self imposed pressure, not the last minute pressures.
  10. Ability to enjoy work – When did you miss your office last, when you took a leave?. Is this an Utopian question?. On many occasions, the agile team members call their colleagues to find out the status and to know about what happened in the daily stand ups and the burn downs. Many occasions I have seen scrum masters reminding their team members to have lunch breaks. These are happening again and again. I am witness to it.

This post is motivated by my past one decades agile training and coaching experience. There are many cases where teams tried to be agile and then failed due to several reasons, which I will discuss sometime later. The term ‘ teams truly agile’ is significant while reading this post. 

Agile transition, team level, our recommendation

Here is what worked for us in the past to transition a new team  into a confident, self sustaining agile team.

T1 – The process starts with a one or two days (depending on the number of participants) workshop titled ‘Agile project management using Scrum’.

C1 – The coach works along with the team during the 1st sprint planning meeting

C2 – The coach works along with the team during the day#1 of the sprint

C3 – The coach works along with the team during the sprint review and the sprint retrospective

C4 – The coach works along with the team during the sprint planning meeting of the second sprint


The whole process gets over during the course of the sprint (as per the sprint duration)

The coach will be available to the team for any doubt clarification (online) up to three months after the completion date of this assignment.

Let us start a dialogue. Call 0091 9895372115  email:

Agile Readiness, Implementation and Institutionalization

If we just call a group of people into a room, train them one of the agile methodologies and ask them to do the project in the agile way, things may still work with the illusion of agility. They may get some benefits as well. It is more like someone who buys a DSLR camera and keep clicking in the auto mode. The results could be better than the past, but it is designed to give much more benefits. For optimal and sustainable implementation of agile, one must focus on the organizational readiness, implementation and institutionalization.



  • Requirements management
    • Approvals
    • Product backlog
    • Prioritization
    • Stories
    • Estimation
    • Release planning
  • Stakeholder management
    • Identification
    • Orientation
    • Communication planning
  • Risk management
    • Identification
    • Prioritization
    • Management and tracking
  • Team
    • Selection
    • Training of the agile framework
    • Special training for product owner and scrum master
    • Team seating arrangements and resources
    • Common understanding of the framework
    • Common understanding of ‘Done’
    • Understanding of the agile principles, values and agile manifesto
  • Communication
    • Methods and tools
    • Frequencies


  • Management practices
    • Sprint planning meeting
    • Sprint backlog
    • Information radiators
    • Sprinting
    • Daily stand ups
    • Burn down chart
    • Sprint review
    • Sprint retrospectives
    • Velocity calculations
  • Engineering practices


  • Commitment to agile even under pressure
  • Motivation
  • Alignment with the performance appraisal systems
  • Interfacing with other systems within the organization

An integrated and systematic approach will help teams and organizations to reap the real benefits of agile like;

  • Better productivity
  • Faster return on investment (ROI) for the customer
  • Better quality
  • Better predictability
  • Highly motivated and capable teams