Many students ask me how to choose a pilot? To ensure success of your transformation, it is really important to choose a right pilot. Below I will give a few suggestions. These suggestions have worked for me in while choosing an Agile pilot.

1. Select a “Visible but not critical project”. It is important to choose a project that has visibility across organisation. This will make the next steps of spreading agile easier. When we select a visible project, it becomes difficult for detractors to dismiss the success. At the same time be wary of selecting mission critical projects. Too much is riding over success of such a project. In this case, the team will be less likely to experiment. The stakeholders will be even less likely to have the necessary patience.
2. Size Matters!! I usually suggest to select project which is not too large. A large project has additional scaling challenges. These become an overhead while trying to implement agile. Usually not more than 3 scrum teams is a nice rule of thumb to follow. I also caution against selecting a too small a team. Such project may also mean a success which is not as spectacular to be tooted across organisation. A really small project delivered by a small team is anyway likely to be succeeded and agile would not get the credit for the success!
3. Where possible avoid added complicating factors. If at all possible, it is better to avoid a project with unnecessary complications. Some examples can be, technology which is too strange to the team, a team that is greatly distributed (more than 3 locations) or a team that is too new and still in “forming /storming” stage. Changing way of work to Scrum is anyway stressful, it is best to avoid further stress. 
4. Select a project that intuitively needs agile It’s best to select a project that has need to evolve requirements – in other words it’s best to have a pilot for starting a brand-new product. It will allow the inherent agile qualities to shine. At the same time, we would avoid added complications of a monolithic architecture or a legacy code base that no one fully understands.
5. On board the champions – Identify your supporters early and include them in your pilot. These people are any way convinced and they will work hard to prove the concept.
6. Avoid The detractors – In the same vein, it is usually prudent to avoid strong nay Sayers. They usually will come on board when they see the pilot succeed. This will reduce the stress of having resistance along every step of pilot

The post Choosing Right Pilot for Agile Implementation appeared first on World Of Agile.

The customer-supplier relationship is a reality for suppliers based in countries such as India, China, or the Southeast Asian countries. I was part of the leadership team of an India-based supplier that brought about a transformational change in a large bank in the Netherlands. One of the things that we (supplier and customer) focused on to get the team to concentrate on the end goal was end-user satisfaction through the implementation of a “one-team” culture.

Senior management buy-in

All of us on the leadership teams (supplier and customer) realized that an Agile transformation is not achievable if only the development teams were practicing Agile. The key was to have management align with the Agile thought process. This involved training management and opening discussions between key leaders from the supplier as well as customers. I was lucky to have worked with a few of the great thought leaders from the Dutch bank who started thinking of all the suppliers as “one integrated team” (way beyond just being a partner who delivers products for a customer). The focus changed from achieving service levels to achieving business goals, and the leadership discussions changed from service-level reviews to strategy discussions on meeting business goals through the one-team culture.

Cultural sensitization

Implementation of a one-team culture also involved cultural sensitizations. Indians had to understand the Dutch culture and the Dutch had to understand the Indian culture. This meant knowing each individual, their families, the way they work, the way they talk, the way they respond, etc. We focused on cultural sensitization sessions to understand each other’s cultures. We celebrated each other’s festivals. We appreciated each other’s games (cricket, hockey, football). Essentially, we started getting close to each other, just like one large family.

Engagement is about a “What can I do for you?” mindset

Most relationships fall apart because you always end up thinking about what you can get out of a relationship. We (the bank and suppliers) worked with our teams to make them understand that engagement and relationship are instead about what you can give to a relationship. We realized that once this is established firmly in everyone’s mind, the engagement between customer and supplier changes from a customer-supplier engagement to a one-team engagement.

Colocation at supplier’s premises

The customer and supplier teams have to work together if they want to achieve anything near to a one-team culture. We saw that the supplier teams made up 80 – 90% of the total teams. It was commercially impractical to have the supplier teams travel to the Netherlands. Doing so would have put unprecedented pressure on the budgets. We decided to have some of the key customer team members, such as product owners or architects, travel to Mumbai or Bangalore to work with the development team for extended periods. This helped reap the benefits of colocation and at the same time build a one-team culture.

Inter-supplier collaboration

When we worked on the Dutch bank projects, we realized that it was a combination of work done by multiple suppliers and customers located at multiple locations. The one-team culture is not only about taking the initiative between a customer and a supplier but also the suppliers’ efforts that must bring about a similar culture to be able to work with each other.

We had local communication channels in India among different suppliers working for the bank; that is, we tried to resolve situations between Mumbai and Delhi teams instead of taking a Mumbai–Amsterdam–Delhi channel. This involved consciously picking up a phone and speaking to other suppliers, inviting other suppliers for customer meets, having team members working from each other’s premises, etc.

Alignment with business KPIs

The initiative was to not think service-level but to think business KPIs. This was the brainchild of the bank’s CIO who inspires me even today. All suppliers and customer teams work toward the business KPIs, which was measured frequently.

We observed that most of the time, whenever it concerned a specific situation or project, it was all about the perception of the business. Getting the business involved in terms of providing inputs overall and everyone (supplier and customer) taking accountability for the inputs was critical. All of us, including the suppliers and customers, put a portion of our “money on the table” and drew from it only when we delivered what was required by the business. To be fair, it was not about the money on the table, it was about getting it in our blood that we were delivering business value and business satisfaction. It was not about delivering a few projects.

Conclusion

The success of Agile beyond colocated teams lies in Agile leadership (supplier and customer) accepting that the large development teams may not ever travel to the customer’s premises due to commercial and practicality reasons. Also, multicultural and multicountry customer teams are becoming the norm, and so the relationship is slowly moving from many-to-many in terms of customers and suppliers. Going forward, customers and suppliers will have to work at developing innovative ways to make supplier and customer teams work like one team to make global projects Agile and ultimately successful.

This article was published on Scrum Alliance member articles on 8th August 2016 – https://www.scrumalliance.org/community/member-articles/1540

The post One-Team Culture – A first step to being Agile appeared first on World Of Agile.

When you do transformation programs, most of you will hear these statement

• “we were delivering projects before, we will continue to deliver projects … how much difference a mere ‘way of work’ can bring?”
• “All this agile and stuff is just a new name for the same old thing. It wont solve my problems“
• “I am doing all this Agile Transformation and stuff because my customer expects me to use the word – Agile”
• “I don’t believe in all this Agile Transformation and Stuff, however, if I don’t use these words and jargons, I will be left behind – And I need the god-damn promotion”

Many of us have come across this resistance when people don’t perceive any real value to them by going agile. They believe 

I have had some of my most notable successes, when I shifted the focus away from agile structure ( the events, artefacts and rules) to agile values and principles. I ask the stake holders a simple question 

“List some of your pain points in current way of project execution” 

Almost everyone has a long list of items that they claim are painful. I then move along further – In an ideal world – how these painful items would change? After I manage to do chip at the usual reluctance, we get to the meat – people start listing out things that they believe will help. Now we are in business. We then identify items that will bring most value to the organizations. These then become the value objectives for the transformations.

Some points to keep in mind are

• Make sure that the items you identify, are adding real business value to stakeholders. Its easy to have items that describe the behaviour and not the result. We all are used to tracking progress based on activities completed not results achieved. For example “code review done” is a behaviour – the value can be “zero defect production release”.
• Items on the Improvement Backlog should be quantified and you agree on measurable acceptance criteria before the item is taken up for execution. “10% improvement in time to market” is a better objective than “reduction in delays”
• When the Skeptical stakeholders see that their real problems are getting addressed, and more importantly they are able to project the results to their bosses, they feel happy in trying out the next set of items.
• It is important to keep the interest of the stakeholders, otherwise they lose interest quickly. Short sprints that show at least some measurable results is the best way to keep their interest alive and kicking.

The post Define Tangible Agile Transformation Items with concrete Business Value appeared first on World Of Agile.

Issue with Big-Bang Agile Transformation

Most Agile Transformations start off as bing-bang implementations spanning across multiple years. Most transformations result in a lot of heartburn and a loss-of-focus since no tangible result get achieved in a short term. Thus the budgets for transformation get consumed quickly and then the questions about “what results you have achieved from running the transformation?” get asked – eventually budgets getting pulled off or clipped.

Designing Transformation Sprints

A good to way to conqueror this can be to design the transformation as a series of “transformation-sprints” which together deliver the large enterprise “transformation-vision”. Each sprint individually delivers at least a small, tangible piece of that large goal. Success is always sweet. When success is achieved in incremental manner, the teams get confident and also the leadership develops confidence that the money spent is put to good use. My experience is that these sprints should not be too short. They should be one month long. Generally one month is a good timeframe for getting tangible results.

Use Scrum Events and Artifacts for Inspecting and Adapting the Transformation

I suggest that these sprints follow the scrum events and artifacts. It allows the team to collaborate in a structured manner.

• A Product Backlog with improvement items in it which are ordered makes a lot of sense. It is usually a good idea to use Themes or Attributes since the teams working on these items are many.
• A Sprint Backlog is a short-term plan which has to be achieved during the month. Each team should decide its own Sprint Goal and should have a own Sprint Backlog
• Sprint Planning for one month should be used as described by LeSS framework – i.e. divide Sprint Planning into “Sprint Planning 1” and “Sprint Planning 2”. Sprint Planning 1 is an overall Sprint Planning. Sprint Planning 2 should be for individual teams to plan their own Sprints.
• Daily Scrum for individual teams to sync for 10-15 minutes everyday makes a lot of sense.
• Sprint Review is the most important event which presents the results achieved to the stakeholders. Stakeholders who are spending money for a initiative would be keen to know how their money is being spent.
• Sprint Retrospective to improve the next month makes a lot of sense again since the transformation itself is an improvement initiative. My advice is that one should do 2 levels of retrospective – one internally and one externally. 

The post Planning Agile Transformation Sprints appeared first on World Of Agile.

In my experience, Agile Transformation can be run as any other Scrum implementation. Thus creating an Improvement Backlog which is an ordered list of everything that needs to be done during the transformation can be created.

Some items which need to be considered

Each Item must have a tangible Business Value

Generally the leadership teams are used to running such initiatives as long term plan-driven initiatives. Thus what ends up happening is that, the list of improvement items becomes a planned list of activities rather than having some tangible business value. The most important thing in a transformation exercise is to define the tangible business value with each item so that everyone knows “Why are we doing this item”. It helps to consciously call out the business value attached with each item. Over time this becomes a habit but it needs attention and focus initially while the team is getting used agile way of working

Ensuring that the Items are small

When the leadership teams are used to running big-bang transformation items, each item spans across multiple months. In my opinion, each item should be small such that a quantifiable value is achieved within one month time.

Acceptance Criteria should be defined

Measurable Acceptance criteria defines when an item is successful. This helps the implementation team get confidence about the implementation being done is resulting in tangible business value. In large transformations, there always will be “Skeptical” stakeholders and “Change Resistant” stakeholders. This way of working helps silence such stakeholders. 

Consider Creating Themes

For a recent transformation I was a part of some of the initial items in the backlog were 

• Increase Scrum awareness, 
• Create a supporting organization structure that enables scrum and Increase automation
• Training
• Spreading awareness of tools
• Re-arranging of the team-space (working area) of teams

Each of these items needed to be implemented by completely different teams. Hence, managing the backlog was becoming a difficult task and we ended up creating a “sort-of” sub backlog for each of the items in the parent backlog. Another way of thinking is that we create Themes in the product backlog which clearly identify the set of items to be undertaken by each team.

The post Running an Agile Transformation with an Improvement Backlog appeared first on World Of Agile.

A burn up chart tracks progress towards a projects completion. In the simplest form of burn up chart there are two lines on the chart: 

·         A total work line (the project scope line)

·         A work completed line

A burnup chart clearly shows both completed work and project scope. The project will be completed when the lines meet. 

The vertical axis is amount of work, and is measured in units customized to your own project. Some common units are number of tasks, estimated hours or story points (in agile project management methodologies). The horizontal axis is time, usually measured in days. 

At each day you can see the amount of work completed and the total amount of work. The distance between the two lines is thus the amount of work remaining. When the two lines meet, the project will be complete. This is a powerful measure of how close you are to completion of the project, similar to a burn down chart. 

Regularly checking progress charts such as burn down charts or burn up charts is an important part of project management, agile, scrum or otherwise. These charts can allow you to instantly identify certain types of problems, such as scope creep or a deviation from the planned project path. These problems can then be discussed and corrective action can be taken at an early stage, rather than when it is too late, the hallmark of an effective project manager. Sharing these charts with customers can also build confidence and trust in both your management, and the progress of the project as a whole. Burn up charts are particularly commonly used in agile and scrum software development methodologies. 

The advantage of a burn up chart over a burn down chart is the inclusion of the scope line. It clearly tracks when work has been added to or removed from the project. It also allows you to visualize a more realistic completion date for the project, by extending a trend line from the scope as well as the completion line. Where the two trend lines meet is the estimated time of completion. 

The scope line allows you as a manager to easily spot where work is being added which will affect the completion date. Whether this work is being added by the client or the team, it is an important signal that the completion date may need to be moved in response. The scope line also tracks where work is being removed to meet a fixed deadline. Again this is important to know as it may impact the quality or functionality of the project, and is something that needs to be clearly discussed with the client and team. 

Although a typical burn up chart only has two lines, other lines are sometimes included. Firstly an ‘ideal’ line may be included. This shows the completion necessary at each day to meet the deadline. You can then tell if the project is ahead of or behind schedule by whether it is above or below the ideal line, and the distance gives you an idea as to how far ahead or behind schedule it is. (The ideal line is usually based on the most recent available total scope for simplicity) burn up chart with ideal line A burn up chart with an ideal line, showing where the project is ahead of and behind schedule. 

Another line that is sometimes included is the required burn up line. This line shows how much work must be completed to meet the deadline, given the current scope. 

Lastly, several burn up charts can be superimposed on top of one another. This is typically done for multi stage projects, such as release versions or development sprints in a software project. The scope lines are cumulatively stacked, whilst the completed line is either combined for all releases, or only for the next release and previously completed releases on any given day. The advantage of this layout is that it is clear when work is being shifted from one sprint to the next, as opposed to being added to the total project scope. More advanced, but also more complicated to read than a burn up chart is a cumulative flow diagram. 

The post Burn Up Chart appeared first on World Of Agile.