Clarity in what we want, why and when helps in maximizing the amount of unwanted work not done, which is one of the key foundations of agile. Agile frameworks provide great opportunities to add value to the client’s business better and faster, than the waterfall model. Lot of proactive agile thinking is required from the client’s (CIO, CFO, Business analysts, PMO, Portfolio management) side to leverage these opportunities of agility. Alignment of the Organizational strategy for growth, Project portfolio, I.S portfolio is of great importance before the start of development of the products, features which really deliver the strategic competitive advantage to business. Here is the opportunity for the CIO, and the business analysts to deliver great value to their organization by inquiring about the following;
What is the organizational strategy for growth?
Every CIO and the business analysis group must understand their business goals and the organization’s strategy for achieving the business goals, so that they get the larger picture which will trigger thought.
What are all the projects the organization is performing to support the strategy for growth?
A peek into organization’s project portfolio management system (You are lucky, if there exists one, else treat it as an opportunity to attempt one) will provide you with the necessary details of all the key projects the organization is embarking on and the rationale behind them. This is a great input to identify the information technology component vital for making these projects successful.
Developing the I.T project portfolio which supports the organizational project portfolio
What is the Information technology’s role / potential to make these organizational (functional) projects maximize their contribution to the achievement of the stated business goals?. Develop the I.T project portfolio.
Decompose the products of I.T project portfolio into wishlist of features (product backlog)
This is the time to develop the product backlog (wish list of features)
Classification of the features
Prioritization of the features
Developing the user stories for high priority features
High level estimates (budgets)
Identification of the agile vendors
First cut release planning, along with the agile vendors
Architectural, technology, financial, schedule considerations
Signing the contract with an agile vendor, where the contract type is cost + benefit sharing or T&M, or Fixed price with a cap on the features (story availability is a must here to estimate effectively)
These may seem like a hill of impediments, when we look at these aspects after starting the I.T project, and at the same time these steps are not that difficult for the CIO and the Business analysts to implement. In fact these are great enablers for them to open meaningful dialogues with the functional managers and the senior management. Doing this much proactively will help in maximizing the value by aligning the product backlog, user stories to the organizational strategy for growth and by identifying truly agile vendors who believes in partnering with their clients to create win-win situations.
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 http://www.scrum.org.
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 scrum..it will give you a smooth start.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
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: firstname.lastname@example.org