The blue ocean business analyst

Agile is about maximizing value to the customer by delivering great functionality at a reasonable cost, that helps him to win at his market. It is about helping him to serve his customers better. Gone are the days when the business analysts used to just note down what the end users asked from the system, and transferred them to the development team without any value addition. This shift in focus from conformance to requirements to maximizing value to the customer’s business opens up a plethora of opportunities for the competent and qualified business analyst.  The mind map provided below depicts the ‘business analyst’ at the center of the stakeholder map.

Blue ocean business analyst

• Determines the actual problem to be solved in the organization
• Understands the business issues and challenges of the organization and industry
• Identifies the organization’s strengths and weaknesses and suggests areas of improvement
• Reviews and edits requirements
• Documents the solution to the problem
• Creative problem solving
• Identification of process improvement opportunities
• Feedback collection and sharing
• Communicates functional product and business standards
• Facilitates business community transition from problem state to solution state
• Evaluation of alternative solutions
• Product stakeholder management
• Augmenting the change readiness of the organization
• Product evaluations
• Facilitation and moderation of meetings
• Presentations
• Effective communication
• Enough technical knowledge to converse effectively with technical stakeholders
• Conflict resolution between the business and the technical teams
• Generating enthusiasm about the product
• Facilitates decision making
• Effective management of requirements changes
• Effective tracking of product issues to closure
• Leads the acceptance testing efforts

Development team is not the differentiation to the customer’s business any more. It is the availability of great business analysts who can identify those killer functionality,  that will differentiate his organization from the competition is the key to value maximization. It will even better if those great functionality articulated by the business analyst can move the organization from the bleeding red oceans to the blue oceans.

Anatomy of a User story

Here is a sample product backlog (wish list of features) for developing an online course 

1. The instructor should be able to deliver classes online on a 1 to 1 or 1 to many basis
2. Online assessments and evaluation
3. Discussion board
4. Online payment facility

With this much information it becomes very difficult to estimate it, or to develop it. As a developer these are the questions coming to my mind immediately about the item No.1 which is ‘The Instructor should be able to deliver classes on a 1 to 1 or 1 to many basis’;

Clarifications required;

1. Are they live classes or record and play or is it live classes with a facility to record and play.
2. Can I use third party tools, or should it be developed from ground zero
3. Can I use open source components
4. Can it be just a slide show with voice, or should it be slideshow and instructor video side by side in a automatically synchronized fashion.
5. When there is bandwidth crunch, can I switch off the video
6. Should there be options for streaming high resolution, low resolution
7. Paid streaming Vs free streaming (ad free, faster, offline viewing)
8. For 1 to many, how many concurrent viewers
9. Pass word protection
10. Sharing option
11. Renting option
12. What is the acceptance criteria

This list can be quite a lot, and as an engineer I need clarity on these, else I will not be able to estimate the work involved. These are the first cut of clarifications required. During development I may have more functional / technical questions.

A user story essentially has,

• The product backlog reference.
• The description of the feature to be developed in detail, in a non technical language.
• The conversations section captures the questions and answers that arises during the sprint planning meeting and throughout the development process.
• Acceptance criteria – This section provides the acceptance tests, which will be run during the sprint review. These are defined upfront and documented, so that the engineer can proactively work to on the code, to ensure acceptance.

It is quite possible that a feature is accomplished with the help of multiple user stories. There can be a 1 to many kind of a relationship between the feature and the user stories. A user story must be something which can be declared as done, 1 to 3 days time. Larger user stories in smaller sprints reduces the benefits of ‘fail fast is success’ mantra of agile.

Writing the user stories upfront may appear to be a herculean task for the product owner. Here lies the great opportunity to include the development team also into story prioritization and development by conducting story writing workshops. This has the added benefit of functional knowledge transfer to the team in advance. I am yet to see projects where the entire user stories are written prior to the start of development. Here lies the benefits of Value stream mapping, release planning and sprint themes.

In engineering, what you get is what you ask. Investing time and energy to develop clear cut user stories is key to success in the agile world. The value of well documented user stories to ensure conformance to requirements is even higher. It acts as a medium of communication about the functionality across stakeholders. That is a good investment one can make to ensure success of your product.

Contact me 

About Aby 

Agile planning mind map

I’m Not a Servant – I’m a Host! A New Metaphor for Leadership in Agile?

I’m Not a Servant – I’m a Host! A New Metaphor for Leadership in Agile?.

First break all the rules #Scrum Master

First break all the rules by Marcus Buckingham is one book which transformed me and thousands of managers worldwide into effective leaders ( servant leader)  by providing those 12 great questions, as a road map.. Introduction to the concepts of this research based book, which is written after interviewing more than 30,000 managers worldwide, gave me an actionable road map to transform my managerial style from autocratic to servant leadership.  I recommend this book to all managers, especially those who work as Scrum Masters, would be scrum masters. Movement from the traditional managerial  style of ‘leading from the front’ to the ‘leading from behind’ style that is required to be effective in self organizing teams, could be tricky and painful, till we understand the true spirit of servant leadership. That is where this book helps.  Life is easy, once you master the style which worked for great managers worldwide. Once you master that style, you can manage any good team in this world effectively and with much lesser effort. Get a copy for yourself as a reference book and try to score high on those 12 questions from your team. Once you start scoring between 3-5, see the difference you have made to the team and to yourself. Trust, this helps.

Feature exploration, a top down approach for the #CIO #CXO #Business analysts

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

Vendor engagement 

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.

The scrum founder’s voice

Check out @jeffsutherland’s Tweet: https://twitter.com/jeffsutherland/status/593921523754209280?s=09

Posted from WordPress for Android

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 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.

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.