Myth about creating multiple Sprint Backlogs before first sprint starts

Some teams treat the Sprint Backlog as just a smaller version of the bigger plan (Product Backlog) and start creating baselined Sprint Backlogs for multiple future Sprints. Is this rught way – read on to discover

Common Misconceptions and negative implications

Some teams treat the Sprint Backlog as just a smaller version of the bigger plan (Product Backlog) and start creating baselined Sprint Backlogs for multiple future Sprints. The negative implication of this practice is that the “Inspect and Adapt” cannot happen. This becomes just disguising the waterfall and calling it Scrum.


  • There should only be one Sprint Backlog. This represents the forecast for the current Sprint. At the end of the Sprint, the Sprint Backlog is emptied. All remaining items are taken back to the Product Backlog. All completed and done items are taken into Increment. The reason why this is done this way is to give opportunity to the Product Backlog to be re-ordered if needed.
  • It is possible that the Product Backlog item changes the order since there might be change of business priorities. If the Sprint Backlog is baselined for multiple sprints at the start then an important opportunity for inspection and adaptation is lost.
  • The discussions in the Sprint Planning result into a new Sprint Backlog based on the business objective to be achieved this Sprint. Even during the sprint, the Sprint Backlog emerges – more details get added and new things get clarified.

This article is re-published on WORLD OF AGILE website –

Agile tester : Skills Needed

In last post we discussed about how the role of a tester changes in agile world. To cope with the changed world, a tester needs to acquire a few new skills. This post discusses what exactly needs to be done

Whenever the two words agile and tester come in one sentence, the next word to be expected is automation. While automation does form a part of the skill repository of tester, its not the only skill they need to acquire to fit in agile world.The diagram above showcases snapshot what needs to be learnt new by a tester in order to thrive in this new world!

  1. Scrum Framework – This category is self explanatory 🙂 A good tester needs to know the framework he or she is operating in. In most of the agile projects – the framework is scrum. The Tester needs to know the same
  2. Common Agile Practices Agile projects use some practices not mandated in scrum. Knowing these practices helps the tester. Some practices like TDD/BDD or Integrating testing in CICD pipeline in fact keep more focus on testing. Testers need to learn these practices well
  3. Agile mindset More than the events and artifacts, agile projects are set apart by the principles and values which the team adheres to. It is critical that the testers really need to understand how the thought process differs. An agile project will focus on getting user usable deliverable out at every sprint. This singular goal drives all activities including testing. A tester needs to now wear the hat where he helps the developer ship out defect free code – The focus now is not finding maximum defects but on ensuring defect free delivery.
  4. Feedback loop A tester in agile project works with frequently changing requirements. This necessitates a ongoing discussion between tester and business community as well as developer. The tester should continually update the business community on the testing impact the new requirements have! He also needs to work with developer to pass on insights that he has from his testing till date. These can be typical defects , areas which the tester think will have down stream impact etc. Testers have a wealth of knowledge that can enable the developer to deliver a best in class code. A tester should be conscious of his responsibility to have this constant feedback going. On the other hand, a tester needs to actively seek inputs on how his tests are impacting project. Are they helping to avoid defects in later stages? or they are just a time waste? Having this feed back loop going in both directions will help a tester to do his job efficiently
  5. Involvement In Events – I have seen cases where test team is absent from events like planning , daily scrum or the sprint review. Tester is very much a part of the whole team and needs to be an active participant in each event.
  6. Automation Automation is the word one hears often whenever agile is mentioned. A tester needs to learn not only functional automation but also need to automate test triggers.

GROW Coaching Model

GROW is a proven coaching model to structure coaching experience .

beauty of this coaching model is that it leads to a clearly defined end result through four phases. The coachee is personally active in identifying problems and generating ideas for solutions. As the coachee is actively engaged, the outcome is more likely to succeed

The GROW coaching model encourages learning through experience: reflection, insight, making choices and pursuing them. The success of a coaching trajectory with the GROW coaching model also depends on the time and energy invested into the process by the coachee.

The best part about working with the GROW coaching model is that you don’t need to be an expert in a specific situation to be able to coach the team. This model offers a framework with general questions to elicit objectives , obstacles, options and more without ever needing to offer advice or force any particular direction.

The steps in the GROW coaching model

The GROW coaching model consists of four steps. The word GROW is actually an acronym for Goal – Reality – Options – Will. This GROW coaching model enables you to to plan a journey. You start with the map: where are you going (Goal) and where are you starting from (Reality)? It then charts the different routes and modes of transportation (Options). At last, it helps you pick the option that suits you best while still considering the obstacles on the way.

GROW coaching model – Step 1: Goal

The first step in the GROW coaching model is defining the goal of the coaching initiative at hand. You will need long term (the central theme ) and short term (the goal for every session)goals.

Goals need to be SMART: Specific, Measurable, Acceptable, Realistic and Timely.

Example questions to identify the goal:

  • What Will help us achieve defect free code?
  • Why a defect free delivery will benefit the team?
  • What it means to be defect free? How do you define it?

GROW coaching model – Step 2: Reality

Step two of the GROW coaching model is making coachee aware of the actual situation on the ground . The coache’s role here is to stimulate thought with the coachee, and to identify the obstacles that have been holding the client back.

It’s important to stay out of the equation in this phase; people have patterns and stories they can repeat and expand on endlessly. Keep on summarising and repeating what you understand from the coachee. Often, this phase of the GROW coaching model reveals underlying fears and convictions that can be worked on during or in between coaching sessions.

Example questions to discover the reality of one’s client:

  • Hows the code quality now?
  • How do you know the current code quality is poor?
  • Why is the code quality poor?
  • Why it is problem to have a poor code quality?
  • What are concrete examples of this problem?
  • What’s been going wrong so far?
  • Is this always a problem or are there situations in which it isn’t?
  • What have you done so far?

GROW coaching model – Step 3: Options

Step three of the GROW coaching model is to generate ideas that can contribute to the solution of the problem. Try to start a creative brainstorming process without censure or conditionality. Generate solutions, then structure it to evaluate every option. If needed, you can also offer some suggestions.

Example questions to generate options:

  • What else could you do to improve code quality?
  • What would you do if you did not have a hard time pressure ?
  • What else do you need to reach your goal? Where can you get it?
  • Which criteria will you use to evaluate this option?
  • What are the pros and cons of this option?

GROW coaching model – Step 4: Will

The fourth and last step of the GROW coaching model is the choice of one option. This is converted into a concrete plan of action. Then the coachee’s motivation to follow this plan is maximised.

Example questions to maximise the will:

  • What exactly will you do to improve the code quality and when?
  • Which of these options will you take?
  • What concrete step can you take NOW to improve the quality?
  • What steps come after?

Power Questions – A really powerful technique

An agile coach is an influencer and not an enforcer. This means he does not get to dictate what approach a team will choose. In agile, development team decides what and how of their actions! In such a situations, asking leading or probing questions is one of the most powerful tools in the coaches arsenal

What Are Power Questions?

If you ask the wrong questions, even incomplete questions, you’ll probably get a wrong answer, or at least not quite what you’re hoping for.

Asking the right question is at the heart of effective communications and information exchange. By using the right questions in a particular situation, you can often make the recipient reach the conclusion you want them to. . Rights questions will help you gather better information and learn more, build better relationships and help others to learn too.

Following are some type of questions and also some guidance on when to use and when NOT to use them.

Some Important Power Questions?

Open and Closed Questions

A closed question usually receives a single word or crisp , Boolean answer. For example, “Was the sprint on time?” The answer can only be “Yes” or “No”; “How many defects did we have?” The answer is generally a number.

Open questions encourage more in depth answers. They usually inquire about elements of what, why, how. An open question asks the recipient for his or her knowledge, opinion or feelings. This engages the recipient in more constructive manner “Tell me” and “describe” can also be used in the same way as open questions. Here are some examples:

  • What did you observe in sprint planning?
  • Describe how your typical daily scrum goes…
  • Tell me about your feeling about this issue
  • Why do you think the sprint had so many quality issues?
  • How did he react to that?

Open questions are good for:

  • Initiating an open dialog: “What was your experience with automating system test?”
  • Provoke thought : “What else do we need to do to make this a success?”
  • Finding out the other person’s opinion : “What do you think about those changes?”
  • Collect more details “Was there something else that we need to know?”

Closed questions are good for:

  • Testing understanding, yours or the recipient’s: “So, if I get this automation done, build wont break?”
  • Ensuring that everybody is on same page “Now we know the facts, are we all agreed this is the right course of action?”
  • Creating a background: “Are you happy with the code quality?”

A misplaced closed question, on the other hand, can kill the conversation and lead to awkward silences, so are best avoided when a conversation is in full flow.

Funnel Questions

This technique involves starting with general questions, and then funneling down to a more specific point in each. Usually, this will involve getting in more and more detail . Detectives often use this techniques while taking statements from witnesses

“How many people were involved in the fight?”

“About ten.”

“Were they kids or adults?”

“Mostly kids.”

“What sort of ages were they?”

“About fourteen or fifteen.”

“Were any of them wearing anything distinctive?”

“Yes, several of them had red baseball caps on.”

“Can you remember if there was a logo on any of the caps?”

“Now you come to mention it, yes, I remember seeing a big letter N.”

Using this technique, the detective has helped the witness to re-live the scene and to gradually focus in on a useful detail. Perhaps he’ll be able to identify young men wearing a hat like this from CCTV footage. It is unlikely he would have got this information if he’s simply asked an open question such as “Are there any details you can give me about what you saw?”


When using funnel questioning, start with closed questions. As you progress through the tunnel, start using more open questions.

Funnel questions are good for:

  • Finding out more detail about a specific point: “Tell me more about Option Two.”
  • Gaining the interest or increasing the confidence of the person you’re speaking with: “Have you used the IT Helpdesk?,” “Did it solve your problem?,” “What was the attitude of the person who took your call?”

Probing Questions

Probing questions is another strategy to get to depth of an issue. Sometimes it’s as simple as asking your respondent to elaborate “I did not understand your point about automation , can you please expand?” At other times, you need additional information for clarification, “When do you need this report by ?” Or to ascertain facts about what has been said, “How do you know that the new database can’t be used by the sales force?”

An effective way of probing is to use the 5 Whys  method, which can help you quickly get to the root of a problem.


Use questions that include the word “exactly” to probe further: “What exactly do you mean by fast-track?” or “Who, exactly, wanted this report?”

Probing questions are good for:

  • Gaining clarification to ensure that you have the whole story and that you understand it thoroughly.
  • Drawing information out of people who are trying to avoid telling you something.

Leading Questions

Leading questions try to lead the respondent to your way of thinking. They can do this in several ways:

  • With an assumption – “How late do you think that the project will deliver?” Here you assume that the project will certainly be late !
  • By adding a personal appeal to agree at the end – “Lori’s very efficient, don’t you think?” or “Option Two is better, isn’t it?”
  • Phrasing the question so that the “easiest” response is “yes” – People naturally prefer to say “yes” rather than “no”. This psychology plays an important part in the phrasing of questions: “Shall we all approve Option Two?” is more likely to get a positive response than “Do you want to approve Option Two or not?” The “shall we” part of the questions brings you and respondent in one group while the “do you” puts the respondent in opposite camp.
  • Giving people a choice between two options – both of which you would be happy with, rather than the choice of one option or not doing anything at all. Strictly speaking, the choice of “neither” is still available when you ask “Which would you prefer… A or B?” but most people will be caught up in deciding between your two preferences.

Note that leading questions tend to be closed.

Leading questions are good for:

  • Getting the answer you want, but leaving the other person feeling that they haven’t got a choice.
  • Closing a sale: “If that answers all of your questions, shall we agree on a price?”


Use leading questions with care. If you use them in a self-serving way or one that harms the interests of the other person, then they can, quite rightly, be seen as manipulative and dishonest.

Rhetorical Questions

Rhetorical questions aren’t really questions at all. They they don’t expect an answer. They’re really just statements phrased in question form: “Isn’t John’s design work so creative?”

People use rhetorical questions because they are engaging for the listener – as they are drawn into agreeing (“Yes it is and I like working with such a creative colleague”) – rather than feeling that they are being “told” something like “John is a very creative designer.” (To which they may answer “So What?”)


Rhetorical questions are even more powerful if you use a string of them. “Isn’t that a great display? Don’t you love the way the text picks up the colors in the photographs? Doesn’t it use space really well? Wouldn’t you love to have a display like that for our products?”

Rhetorical questions are good for:

  • Engaging the listener.
  • Getting people to agree with your point of view.

Difference Between Agile Coaching Mentoring and Agile Training

A scrum master needs to be skilled in Coaching, Mentoring as well as Training. Each of these activities have a considerable overlap. Each involves helping people to improve their performance.


Training involves an expert (trainer)imparting a certain knowledge or skill to other people (trainees). A trainer is not usually involved in day to day activity. Its a structured activity revolving around sharing the said knowledge or skill.


Mentoring on other hand,  is a system of semi-structured guidance whereby one person shares their knowledge, skills and experience to assist others to progress . Mentors usually are SMEs or experts who have traveled the path before and possess answers that will help the mentee. Coaching


Coaching is a form of development in which a coach supports a learner in achieving a specific personal or professional goal. In other words, coaching is about a Coach unlocking the potential of the coachee. Here the coach may or may not have the answers. His role does not include handing over the answers on a platter. The coach helps the coachee to discover the answer himself.

How Agile Coaching, Agile Mentoring and Agile Mentoring differ?

A skilled scrum master needs to understand the difference between the three activities. He needs to be able to use the right tool for right situation. I have tried to list the key differences below.

 What is It?Duration & RelationshipWho Drives it?ModelsGoal
Agile TrainingImparting new skills
Or knowledge to the trainees
Usually short term. Is a transnational activity . Training is normally one to many where each trainee participates in individual capacityTraining is driven by the trainer - He/She decides the methodology and the model of the trainingMultiple models like classroom instruction , discussions , demonstrations , hands on exercises may be usedIncreased Skill or Knowledge for the trainee(s)
Agile MentoringHelping the mentee to reach the answers and achieve towards a certain goalUsually Long term. Its an ongoing hand holding till the mentee reaches the goal.Mentor , who is SME drives the direction and modelMore intimate one on one way extended via discussion or thought provoking questions. Mentor will help the mentee outline his options and choose oneBetter clarity for mentee
Clear plan of progress
Agile CoachingDevelop existing skills to enable the team reach a better stateUsually medium term - lasting a few months to couple of years

Agile coaching is usually in a one to many form where the coachees participate as a team
Here the coachess are the ones in driving seat. Coach will subtly influence but he can not enforce the way a coaching goesCoaching usually happens where coach helps the team to reach a stage where they them selves will find the answerBetter on the ground application on skills and knowledge

Agile Coaching

With so many organizations adopting agile, “agile coach” has become a very important and in demand role. In industry today we see a common confusion around this this role. What does an agile coach do? What do you actually mean by agile coaching? These are the questions with many scrum masters struggle.

In this section, I am planning to write about my perspectives about agile coaching , what skills are needed by a good agile coach. What are some effective techniques to use?

Stay tuned and read along


DevOps (a clipped compound of “software DEVelopment” and “information technology OPerationS”) is a term used to refer to a set of practices that emphasize the collaboration and communication of both software developers and information technology (IT) professionals while automating the process of software delivery and infrastructure changes.

It aims at establishing a culture and environment, where building, testing, and releasing software can happen rapidly, frequently, and more reliably.

DevOps isn’t a framework or methodology in and of itself. It doesn’t stand alone. DevOps adopts and leverages multiple frameworks and philosophies such as Agile, Lean and ITSM. DevOps is benefitted tremendously from the work the Agile community has done, showing how small teams, operating with high-trust, small batch sizes with smaller, more frequent software releases, can dramatically increase the productivity of development organizations. DevOps applies Lean principles such as increasing flow and reducing waste to the IT value stream. DevOps requires agile service management processes to remove bottlenecks and achieve faster lead and cycle times. By adopting and adapting practices from multiple frameworks we generate more productivity and economic value for the business.

This series of Blog Posts will address the various myths associated with DevOps and will attempt to address them.

Agile Testing

The Differences between Testing in Traditional and Agile Approaches

Testers must understand the differences between testing in traditional lifecycle models (e.g., sequential such as the V-model or iterative such as RUP) and Agile lifecycles in order to work effectively and efficiently. The Agile models differ in terms of the way testing and development activities are integrated, the project work products, the names, entry and exit criteria used for various levels of testing, the use of tools, and how independent testing can be effectively utilized.

Testers should remember that organizations vary considerably in their implementation of lifecycles. Deviation from the ideals of Agile lifecycles may represent intelligent customization and adaptation of the practices. The ability to adapt to the context of a given project, including the software development practices actually followed, is a key success factor for testers.

Testing and Development Activities

One of the main differences between traditional lifecycles and Agile lifecycles is the idea of very short iterations, each iteration resulting in working software that delivers features of value to business stakeholders. At the beginning of the project, there is a release planning period. This is followed by a sequence of iterations. At the beginning of each iteration, there is an iteration planning period. Once iteration scope is established, the selected user stories are developed, integrated with the system, and tested. These iterations are highly dynamic, with development, integration, and testing activities taking place throughout each iteration, and with considerable parallelism and overlap. Testing activities occur throughout the iteration, not as a final activity.

Testers, developers, and business stakeholders all have a role in testing, as with traditional lifecycles.

  • Developers perform unit tests as they develop features from the user stories.
  • Testers then test those features. Business stakeholders also test the stories during implementation.
  • Business stakeholders might use written test cases, but they also might simply experiment with and use the feature in order to provide fast feedback to the development team.

In some cases, hardening or stabilization iterations occur periodically to resolve any lingering defects and other forms of technical debt. However, the best practice is that no feature is considered done until it has been integrated and tested with the system. Another good practice is to address defects remaining from the previous iteration at the beginning of the next iteration, as part of the backlog for that iteration (referred to as “fix bugs first”).

However, some complain that this practice results in a situation where the total work to be done in the iteration is unknown and it will be more difficult to estimate when the remaining features can be done. At the end of the sequence of iterations, there can be a set of release activities to get the software ready for delivery, though in some cases delivery occurs at the end of each iteration.

When risk-based testing is used as one of the test strategies, a high-level risk analysis occurs during release planning, with testers often driving that analysis. However, the specific quality risks associated with each iteration are identified and assessed in iteration planning. This risk analysis can influence the sequence of development as well as the priority and depth of testing for the features. It also influences the estimation of the test effort required for each feature.

In some Agile practices (e.g., Extreme Programming), pairing is used. Pairing can involve testers working together in twos to test a feature. Pairing can also involve a tester working collaboratively with a developer to develop and test a feature. Pairing can be difficult when the test team is distributed, but processes and tools can help enable distributed pairing.

Testers may also serve as testing and quality coaches within the team, sharing testing knowledge and supporting quality assurance work within the team. This promotes a sense of collective ownership of quality of the product.

Test automation at all levels of testing occurs in many Agile teams, and this can mean that testers spend time creating, executing, monitoring, and maintaining automated tests and results. Because of the heavy use of test automation, a higher percentage of the manual testing on Agile projects tends to be done using experience-based and defect-based techniques such as software attacks, exploratory testing, and error guessing. While developers will focus on creating unit tests, testers should focus on creating automated integration, system, and system integration tests. This leads to a tendency for Agile teams to favour testers with a strong technical and test automation background.

One core Agile principle is that change may occur throughout the project. Therefore, lightweight work product documentation is favoured in Agile projects. Changes to existing features have testing implications, especially regression testing implications. The use of automated testing is one way of managing the amount of test effort associated with change.

However, it’s important that the rate of change not exceed the project team’s ability to deal with the risks associated with those changes.

Project Work Products

Project work products of immediate interest to Agile testers typically fall into three categories:

  • Business-oriented work products that describe what is needed (e.g., requirements specifications) and how to use it (e.g., user documentation)
  • Development work products that describe how the system is built (e.g., database entity-relationship diagrams), that actually implement the system (e.g., code), or that evaluate individual pieces of code (e.g., automated unit tests)
  • Test work products that describe how the system is tested (e.g., test strategies and plans), that actually test the system (e.g., manual and automated tests), or that present test results (e.g., test dashboards)

In a typical Agile project, it is a common practice to avoid producing vast amounts of documentation. Instead, focus is more on having working software, together with automated tests that demonstrate conformance to requirements. This encouragement to reduce documentation applies only to documentation that does not deliver value to the customer. In a successful Agile project, a balance is struck between increasing efficiency by reducing documentation and providing sufficient documentation to support business, testing, development, and maintenance activities. The team must make a decision during release planning about which work products are required and what level of work product documentation is needed.

Typical business-oriented work products on Agile projects include user stories and acceptance criteria. User stories are the Agile form of requirements specifications, and should explain how the system should behave with respect to a single, coherent feature or function.

A user story should define a feature small enough to be completed in a single iteration. Larger collections of related features, or a collection of sub-features that make up a single complex feature, may be referred to as “epics”. Epics may include user stories for different development teams. For example, one user story can describe what is required at the API-level (middleware) while another story describes what is needed at the UI-level (application). These collections may be developed over a series of sprints. Each epic and its user stories should have associated acceptance criteria.

Epics can be easily broken down into user stories by slicing them vertically and they comply to INVEST criteria. Each Epic and user story contains acceptance criteria with necessary business rules and mockups attached to them.

Typical developer work products on Agile projects include code. Agile developers also often create automated unit tests. These tests might be created after the development of code. In some cases, though, developers create tests incrementally, before each portion of the code is written, in order to provide a way of verifying, once that portion of code is written, whether it works as expected. While this approach is referred to as test first or test-driven development, in reality the tests are more a form of executable low-level design specifications rather than tests.

Typical tester work products on Agile projects include automated tests, as well as documents such as test plans, quality risk catalogs, manual tests, defect reports, and test results logs. The documents are captured in as lightweight a fashion as possible, which is often also true of these documents in traditional lifecycles. Testers will also produce test metrics from defect reports and test results logs, and again there is an emphasis on a lightweight approach.

In some Agile implementations, especially regulated, safety critical, distributed, or highly complex projects and products, further formalization of these work products is required. For example, some teams transform user stories and acceptance criteria into more formal requirements specifications. Vertical and horizontal traceability reports may be prepared to satisfy auditors, regulations, and other requirements.

In some regulated agile projects, more inspection of the documentation that is being produced during the project execution may be required.

For example: Federal drug administration (FDA) projects require lot of audit reports, strategy reports and compliance reports that need to be produced during the project execution.

Manual Testing is Obsolete – Career progression for testers

Aggressive and exhaustive manual testing has long been seen as an mandatory task that took as much as 30 % duration of the entire life cycle and 35-45 % of the effort of entire software development life cycle. This focus on dedicated manual testing has led to creation of an army of manual testers. These career testers have often spent many years doing manual testing and do not have very well developed technical skills.With agile becoming predominant, the focus is now on end to end working product delivered by a cross functional team. This creates a question of existence for the dedicated manual tester.

In my daily work I meet many such people who have done manual testing for 10- 15 years and now are worried about what next? This post is for them

Focus On What The Manual Testers Can do? Often the testers are worried about quickly acquiring new technical skills. They have not done any “coding” for last few years and starting fresh scares them. Best way is to think what they do know. I have seen usually these testers have tested the same system for a long time and have gathered an enormous knowledge about end to end system working. This domain knowledge is a hot commodity in agile world where working software in a short time is the key expectation. It then makes most sense to leverage this domain depth and build on top.

  1. For those Who Want To Remain In Testing For those who enjoy the the world of testing, the options are in 2 areas
    1. Entering the Automation World – These days BDD tools like cucumber allow for easy UAT automation. The major skill lies in understanding the end to end functionality and deciding what to automate. Even functional automation tools like Katalon Studio require minimal amount of coding. This option does involve learning some new skills but learning those does not need a tester to learn extensive coding. An activity which many testers do not seem to enjoy , Re skilling Needed is learning about automation tools. Usually takes 3-6 months
    2. Test Strategist at Enterprise level As the application sizes grow , balancing the test coverage with available cost and time becomes more and more difficult task. A test strategist analyzes the application and the project needs to recommend types and phases of testing needed for current project – what and when to automate. , Up skilling Needed to fill in the gaps about application knowledge and learn latest testing trends and techniques
  2. For Those Who Want to Step Out Of The Test World For those who want to leave the testing world behind , the domain knowledge they have amassed becomes an excellent opportunity
    1. Starting Out As a BA – With their system knowledge most of the testers make excellent bridge between the domain guys and the technocrats. Both of these people often talk seemingly different language and having a Business Analyst in team is often priceless. ,Up skilling Needed to increase depth of domain knowledge , some executional skills like writing a good user story may need to be acquired. The executional skils are easy to aquire and usually do not take more than 2 months or so
    2. Path to PO – As a next step from the BA, good domain expert can aspire for a role as PO where they leverage their domain knowledge to decide the path the product takes. Up skilling Needed to increase depth of domain knowledge , understand industry trends. some agile skills like understanding empirical product development , managing the product backlog , vertical slicing etc may need to be acquired.

Agile Transformation in An Agile Manner :: Form an Agile Team

Transforming the way of work to agile will be a one most effort consuming work your organization will take up. The team composition and roles need to be well thought out to ensure relatively smooth transformation. (The work anyway will be volatile enough!). Some of the key criterion to keep in mind while forming teams are

  1. Members who have influence – For a change that is all pervasive, it is important to choose stakeholders who can influence the change
  2. Members Who Are Excited – Having members who are excited about the change will make the initial part easier
  3. Diverse Skills Scrum is pervasive. So to adopt scrum we need changes in organizational process , technology , org structure , skill building – its essential to have people who can manage these diverse areas of impact
  4. Have a Sponsor – Choosing a sponsor who can not only influence but is also actively engaged with the team.He should be the leader who is engaged enough that he encourages others to be drive. Some of the most successful agile transformations have the sponsor as a product owner. This then ensures that his vision gets implemented. 
  5. Consider Chapter teams – Chapter teams are the horizontal teams who take up a specific item on the backlog and then drive it through the organizations. They usually end up having a sub blog for their own area of improvement.We discussed this sub log structure in earlier post
  6. “Two in a Box Coach team” At times it is helpful to have a combination of coaches – Internal and External coaches working together. External coaches are able to bring outside perspective and they are in a better position to influence senior management in their capacity as “expert consultant” . At the same time, internal coaches are better able to understand pulse of organization and carve out action items that actually work 🙂