10 things that agile teams can do in a retrospective

"Today should always be better than yesterday" - mother of Gabby Douglas, the first African American to win individual all-around gold and the first American to win gold in both the individual all-around and team competitions in gymnastics.

A retrospective provides the opportunity for teams to get together and tweak "something" that impacts their outcomes so they achieve better results than before. Teams use retrospectives for joint learning, making a decision, choosing an action or strengthening a common bond. In Scrum, retrospectives are held at the end of each sprint. Kanban is non-prescriptive about retrospectives, but most kanban teams end up doing retrospectives at a regular interval or an as-needed basis.

Noted that some teams resist the retrospectives and lose them entirely. Why does that happen and what is the impact? Well that's another article for later.

Here is we look at the positive side and some of the ways that agile teams use retrospectives to their advantage. This list is but a small subset of many possibilities on what agile teams can do in a retrospective!

1. Discover team strengths, weaknesses and opportunities: Retrospectives are avenues for team members to discover what the team is doing well and where it can make improvements.
2. Raise the bar on their own performance: Based on the strengths and weakness, Agile teams inspect and adapt, either improving their performance or adjusting to new situations they encounter in order to stay on course.
3. Prioritize problems that the team must address: Teams usually identify multiple problems and areas of attention during the retrospective and then they narrow down what is most important for them to solve.
4. Solve difficult problems: At times, the team identify a particular problem that needs to be solved without even going through the rigor of listing and prioritizing the problems. Teams deploy various problem solving techniques, such as root cause analysis or five whys, or even discussing the results of an A3 process together.
5. Review data, important trends: Scrum Masters and others in the team may collect important data and trends for the team to review during the retrospective. The data can be anything related to the team's functioning, or related to an important issue that the team would like to resolve. Looking at the data together often produces new insights for all team members and helps finding the best way to resolve the problem.
6. Ask for organizational and leadership support: Depending on the organization, some problems may be beyond the team's sphere of influence. By prioritizing and discussing possible solutions, the teams make a case for change that would impact them positively.
7. Cheer, appreciate, express gratitude: Retrospectives can also be one of the forums to celebrate success on completion of a hard initiative, an effort or any activity that the team undertook. Teams utilize the retrospective to bond together and appreciate each others' strengths and contributions and thank each other for critical help in completing or making progress towards a goal.
8. Support each other: A healthy team harnesses and extends ideas from its members. Retrospectives are an opportunity to strengthen some of the beliefs and the ideas that team members want to adopt. In that process the team members support each other and make progress on what they think is important.
9. Challenge each other: Not only are the retrospectives meant for supporting ideas, they are also meant for challenging different ideas. Challenging different ideas helps the team narrow down to the one or few that the team wants to try.
10. Experiment: Teams, Scrum Masters and facilitators to experiment with what they do in their retrospectives so they can amplify the value derived from the retrospectives. They can experiment and vary the format, agenda and results they want from the retrospective, or just use it to have a conversation to make changes that are needed.

Lastly, if you are doing Scrum please do not wait for a retrospective till the end of the sprint to have a conversation with your team.

Related:

• Goals of a Retrospective 
• Agile Retrospective Resource Wiki
• Sprint retrospectives
• Retrospectives: Prime directive 
• There's hope (usually!)
• Agile Retrospectives: Making Good Teams Great, by Esther Derby, Diana Larsen  

Rough notes: Misunderstood agile practices

Let us assume management and team have some experience with agile but they only understand parts of it (such as iterative delivery, sprint ceremonies etc.). Have you faced such situations? Which practice(s) and concept(s) did you strive to adopt but were challenged? what tools did you use for influencing the outcomes?
 



Here are some highlights from a LinkedIn discussion I started about misunderstood agile practices.

* In many "traditional" companies agile is seen as a new set of controls to get work done. Old roles are re-labeled.

* Many companies think that they can purchase agile as product also if they have few certified SM/PO on pay roll, company is agile.

* Misconception: Equating testing with quality improvement. Quality needs to be designed in from the get go.

* Try this: Making metrics visible. Nobody can argue with truths, and the truth is a strong motivator of change in group dynamics.

* Conducting honest retrospectives over many sprints is often neglected.

* The biggest mistake that people make is thinking that Agile is a process, and if you do the process, you'll be successful.

* Agile practices could be perfectly implemented but with inappropriate mindset and intention, then practices perfectly implemented in physical and visible shapes will all always be misunderstood.

* Misunderstanding Being Agile vs. Doing Agile: Most people don’t understand the difference between Being and Doing. Agile isn’t something you do. It’s something you are.

* Misunderstanding the proper amount of documentation needed. Reading "Working software over Documentation and Processes" and forgetting the final line of the manifesto, "Although we value the things on the right, we value the things on the left more".

* The problem is with the mindset. A mindset change is more difficult of a change and involves coaching/training/teaching and importantly discussions around what Agile is to the team/department/company.

* Many chickens do not understand the "doing" vs "being" agile.

* Misunderstanding: Many organizations associate agile with tools...like "I am using Jira / Rally / TFS /(any other tool you can think of) and still not able to get the benefits of agile. Looks like agile doesn't work for us"!!!!

* Transparency does not mean micromanagement.

* Misunderstanding: Dysfunctional Waterfall is the same as Successful Waterfall.

* Misunderstanding: If I cut my big traditional programme of x years without any reliable progress indicator into small iterations, that I can reasonable expect precise forecasts / commitments and then still get all the benefits of agile.

* Misunderstanding: Agile methodology is not suitable for products which take multiple years to build.

* Misconception: "Agile is for those who are not disciplined enough for processes", i.e. "You can improve Agile by introducing more rigid processes."

* Try this: Look at your dev / test / staging infrastructure and automation around that. And your engineering skills and practices.

* Misunderstanding: Scrum ceremonies often misunderstood and poorly done, but yes Daily Standup especially. As it returns every day.

* Misunderstanding: "We create user stories ñ try to complete them in two weeks" so we follow agile ...

* Misunderstandings: Originally, there are things like "I can't break down my work that small." Or "our testers are used to being at the end, we can't include them in our current sprints." And the misconceptions just move on down the line as you transform the teams.

* Quote: Wisdom begins when we discover the difference between "That makes no sense" and "I don't understand". --Mary Doria Russell

* My favorite takeaway: It is far better to move ahead with a wealth of misconceptions and the personal and organizational intent to continuously improve than to try and identify and correct the misconceptions first.

Five agile concepts that managers should never ignore

Having practiced agile for some years now, I keep running into situations where managers, with all their good intentions, either misinterpret or fail to understand or do not choose implement certain agile concepts due to various reasons. Although that provides them immediate relief the long term pain only aggravates impacting the outcomes, the team and the managers themselves in different ways that are usually not positive.

Are you a manager? Below are five key concepts that you will hopefully find useful.

1. Start right, because if you don't you will put the entire project or initiative in jeopardy. Going through a short term pain or pressure is sometimes necessary if you wish to avoid long term problems with your project. Managing expectations is the key. If your voice is not being heard by higher ups, get help if you have to. It could be someone with more influence or someone with more experience or may be a mentor or a coach who can help you make a convincing argument and even argue on your behalf. Get your team to appreciate why starting right is important. Ally with them to build a convincing case on what works for you.
2. Adapt or Die. If you don't learn from mistakes you will find it hard to survive. This is applicable for you not just as an individual but also for your team. The teams that do not learn from their mistakes and team members that do not learn from each other often run fire-drills as regular way of working. If they are using Scrum, you will often find symptoms such as planning more than what they can do, or ignoring yesterday's weather, and often pulling in new work when the planned work has not been completed yet. Others may abandon Scrum altogether and start using Kanban without applying WIP limits or even visualizing their workflow. Are you a leader of such a team or teams? Why do you think this is happening?
3. Be transparent. At times there may seem to be a tendency and perhaps even an incentive not to disclose information higher up and letting them know what is really happening in your project. There could be many reasons for this situation, organization-created or self-created or just fabricated. When you look into the reasons, think about what is best for you, best for your team, best for your organization and best for the customer - ideally, all the four should have the same answer. If not, dive deeper and ask why is there a difference? Can you do something to remove the difference? If can't do anything about it, are you and your at the right place doing the right job?
4. Promote collaboration, simplicity and excellence. Agile principles talk about collaboration, simplicity and emphasize technical excellence. The reason is that there is usually nothing more powerful than collaborating to deliver successful outcomes along with technical excellence, that motivates a strong development team. As a manager you carry a ton of influence and responsibility to make this happen.
5. Deliver customer value and team happiness. You have demonstrated your success as a manager when your team is delivering functionality that makes customers happy, it is building in quality into the product, and is proud of its accomplishments. Process may be important but it is not the goal

Good luck!

How to increase team velocity? There is no silver bullet but you can try!

Ugh... That question again?

In a discussion forum I came across this comment that "Velocity is an awful term and one that is often weaponized like it has been in this thread by asking how to get more. It's the wrong question because the goal is to become predictable much more so than faster."

I do not agree that velocity is an awful term, but I do agree that it is often misused (and even weaponized). If you intend to use velocity the right way, and are interested in using it as a tool to understand and improve your work outcomes, this post is dedicated to you.

I would like to note that some of my friends are passionate about #noestimate. Whether you go that route or not, is your choice. The important thing is that is the team performing or worrying about numbers and metrics. If velocity discussions are weighing down the team, that is usually a sign of a different problem.

As you go through this post, keep in mind that increasing velocity may not be your real and only problem, and should definitely not be your main goal.

 

Addressing the "Real Slim Shady"...  

If you want to address the issue genuinely please understand there is never really an end.

If the team is rapidly delivering customer value, communicating well and learning from its experience you may only have limited leverage on what the team itself can do. The team may need support from its ecosystem to take it to the next level. At the same time there will still certainly be things that can team can do to make improvements. and is improving velocity the end goal? Or is it delivering customer value rapidly?

Lets address that.

 

Step 1. Who is asking?

Before you go any further it is important to understand who wants to increase the velocity. Many a times someone higher up in the food chain may want to know how you will improve the velocity. It may also be a software developer on the team, the whole team, the product owner or the scrum-master (is that you?) who is interested. Or it may be a stakeholder, project sponsor or anyone else as well. Understanding who is concerned about improvement in team's velocity can help you in several ways in the steps that follow.

Step 2. Why are they asking - their motivation?

Before you jump into a solution, identify why they are asking the team to increase its velocity. What's in it for them (who want the team to improve)? As you dig deep into the reason for asking, you will likely discover the intent (good, bad, helpful, unhelpful) of the person asking the question. You will become sensitive to their needs and discover their situation. Are they interested in improving communications and flow of value or do they have a personal gain in mind by highlighting the problem? Answering why will help not just with framing the response better but also with taking more informed actions. Whatever the reason is, think about how that can help you drive improvements.

Step 3. Draw insights - Where are the problems, what are the solutions?

Based on your study of your context, would it be fair to say there are potential opportunities for improvement? Where could the team do better?

Imagine a team delivering really really fast but the customers are not responding favorably. Could it be lack of quality or delivery of functionality that customers do not need? In either case, increasing velocity may not be the best solution. We need to think smarter.

Try these questions first:

1. Is the team delivering new features and improvements frequently? 
2. How are customers reacting to the product deliveries and latest features? 
3. Is the team generally enjoying their work and having fun?

If you spot problems while answering these questions, search deeper. Here are just a few examples of what you could explore.

People:

• Do measures such as velocity drive positive behaviors in your organization? If not what can be done to fix that situation?
• Are the roles well defined? Is there sufficient empowerment? Are the roles of PO, SM and Development team clearly understood?
• How is communication between the team members?
• How strong is the leadership for your team, project and the organization?

 

Process questions:

• How do you assess progress towards an important goal? Do you have an objective method?
• Are team members working on multiple diverging goals and functionalities and have high work in progress?
• How are releases managed and rolled out - small chunks or big rocks?
• What is the team doing to continuously learn from its journey?
• How are (Scrum) meetings running?

Technology questions:

• How is the team doing on the account of technical debt?
• Is there sufficient test automation and continuous integration?
• How is your quality? Do you have a huge bug backlog?

Draw insights together with the entire team to understand all perspectives and see what can be done. Dig into the backlog, measurements that the team thinks are relevant, such as velocity, cycle time, defect trends, automation, build failure rate etc. Looking for problems, and asking why over and over again, should give you new insights on what can be done.

Shortlist a few experiments to try out.

Step 4. Sell, Try, Feedback, Repeat (Go to step 1)!

As you go through this exercise, you may come up with a range of solution(s). Some solutions may require senior management intervention, others may need more involvement from the team.
Now it is time to channel the conversations around the solutions, convince the stakeholders to try them out. Clarify how you will be reviewing the outcome - set a time-frame for that. Try the solution and get more feedback! You may have to repeat this several times, to continually get the results you are hoping for (including but not limited to an improved velocity, as that may not be the real goal you are after).


Good luck!

There's hope (usually!)...

Imagine things are going completely out of control; ownership and accountability are minimal; there is little willingness to collaborate and not enough leadership to make it happen. You are down with dismay and disbelief at how things are going... feeling blue and nothing seems to move despite your best effort? Imagine yourself stuck in the moment unable to get out! 

Damn.. we wish never to be confronted with a situation like that. Nevertheless stuff happens, at times all we can do is think, and think hard what we should do but answers don't come easy or fast. How can we help change the situation for the better? That is the agile mindset isn't it - inspect and adapt until we find an answer?

What to do?

Should you stay hopeful or quit in despair!? 

I hate to say it, quitting could be an option if you are desperate. It could work in the short term and give you relief, but what would you achieve, what would you solve by quitting? Why not let someone else deal with the mess? Quitting is usually the easy way out, though not always the best.

Why should you care? Before you decide whether to quit or to persevere, try answering these questions:

• Would you learn something new that would prepare you for even greater challenges if you continued to persist instead of quitting?
• Would you get a similar opportunity again... an opportunity to be a part of the solution to a very big or complex problem? 
• Could this be an avenue for you develop and practicing your skills in a particular area that you really want to learn?
• How will the decision impact the organization that you work for, and your colleagues?
• What will make you happy? What about your family and your friends?

I think:

• If you are a kind of person who gets a kick out of bringing positive changes, you will likely enjoy persisting. Things usually change, and although they sometimes change for the worse, but they usually (eventually) change for the better. 
• If you enjoy learning, you will likely want to try and persist longer. You will also try to experiment with options you have not tried before and there is god chance you will succeed when others see value.. and they eventually will.
• If you are very competitive (and perhaps driven by how fast you rise in your career charts!), you will likely calculate the risk/reward possibility around your situation and decide accordingly.

 

 In short...

Whatever you do depends a lot on your situation, and the kind of challenges you are built for as a person - your strengths, weaknesses, values and motivations. Give it a thought, introspect a little and make your choice. Good luck!

So, why plan? A note to self..

Would life be easier if we did not have to think about planning? Let's face it, whether it is about running our day to day routine or even something as simple as paying a visit to the neighborhood grocery store there is planning involved. Imagine taking a vacation without planning where you will go, what you will do while you are there, how long will stay and what you need to bring with you. Or imagine not thinking about how much you need to earn, to save and to invest to meet your worldly needs.. Well lets just keep those worries aside for a few minutes shall we and think about how planning can actually help! Yes that's right, no matter how much burdensome it might sound, planning can help.

What is planning?

The simplest definition of planning that I have come across is "decide on and arrange in advance". I like this because this definition is light, it does not say how much detail we need to plan in, but an important thing that it does say is that planning happens in advance.

Why plan?

There are many reasons why we plan. Our limited information about the future and vision of what we want to do with that information in order to achieve a specific objective gives us an opportunity to play with creative alternatives and paths to get there. Applying constraints helps us narrow down our search of solutions, breaking them down into chunks or steps that are (hopefully) easy to understand and sequence as necessary. When steps and solutions are not known we put on our experimentation hats and navigate our way to discovering the possibilities.

Use the plan as a defense strategy

So what should I tell my teams when they get planning? What are the things I need to keep in mind but don't come easy, specially with Scrum? In my note to self, I include the following.

 

Plan just in time, and just enough.. 

Plan early but not too early. Have a high level roadmap that (can change and) tells the team the path we will take if things went all-right. Planning too much too soon could mean a lot of wasted effort and repetition. Planning too little could mean little predictability in outcomes for initiatives that span multiple sprints. So lets groom our backlog stories and have them ready for a few (may be two to four) sprints to come. Lets find that right balance for our team where Sprint planning sessions do not become painful and burdensome.

 

Plan based on data..

More often than note, teams are asked to meet an "aggressive targets". In other words, there is a huge tendency to ask for deliveries tied to dates without understanding scope and effort involved. These dates are usually based on business constraints and are tight (more often than not). So, organizations and teams find themselves in situations where teams are unable to deliver as some say - "on time" and "within budget". Lets avoid that for our team through scientific and consistent use of measures such as velocity and cycle time. Lets make forecasts based on data so that business understands our non-trivial effort and can make realistic, prudent decisions on scope and priority.

 

Maintain discipline, Estimate or #NoEstimate..

There is much debate on whether to do estimates or not. What seems more important to me than that debate is to agree on an approach that works for our team and for your organization and follow it with discipline. When we estimate, lets spend little time estimating, after all estimates do not produce value for customer, working software hopefully does. Estimates are just that - "estimates", they are "not actuals".

 

High priority, High risk first..

What should the team work on first and what should it work on later? There are multiple factors that decide this, chief among them are dependencies, customer feedback and risk. The product owner plays an important role balancing all aspects while deciding the order so that team delivers value while making continuous progress. So lets keep in mind the problem we are trying to solve, and order our backlog on the basis of that. Lets identify those things that are not clear and run spikes. Lets reduce the risk early as early as we can, so that we do not embarrass ourselves in front of our stakeholders and customers when the time comes.

Minimize hand-offs, eliminate technical debt..

Lots of times, teams work with other teams to deliver an experience or functionality. Many times this needs dependency management, and back and forth discussions. This can lead to side effects such as reduced velocity, need for additional testing to retain quality, development of interfaces and/or APIs etc. When we get into such situations, lets find out if we can minimize dependencies through techniques like creating mockups, and integrate early and often. Let us ferociously automate testing and deployment (at all levels) so that we can identify and resolve issues quickly.

Plan often and monitor, welcome change..

Lastly, should planning be one time? Absolutely not! The team should be ready to embrace change as they get better insights into customer needs and potential solutions. Lets dispassionately accept new stories, reject old ones that are no longer useful and update ones that need to be updated. Once again, an active Product owner and Team partnership can make a big difference. It is not as important to stick to the initial plan as it is to fulfill needs of the customers.

Want to be a Scrum Master - What is your motivation?

Thinking about being a Scrum Master? Have you thought about:
1. What is your motivation and do you think you are the right fit?
2. Would you like it to be a career choice?
3. What is in it for you? Is this role really attractive for you? What kind of growth are you looking for?
4. What does this role mean to your organization?

If you have thought about any of these questions and chose to be a scrum master, you are among the few scrum masters I have come across, who had the chance to do so.

In many cases I have come across, being a scrum master has been a matter of chance, many times imposed, rather than a matter of choice. To me that is an indication of how much (lack of) thought we devote into our role in a team setting as we probably should. As a result, we have multiple cases of job done badly, the role being viewed as "just" an administrative role, or something so easy that "anyone" can do, etc.

 Here I list a few things to think about when you are contemplating this role for yourself.

1. Start with motivation. Ask yourself why you want to be the scrum master, and what do you think you will achieve through that role. If you are a good scrum master, your services will be rewarded through your team's successes (or fast-fails, which should also be considered as successes). Highly successful teams will shine and through them, you will shine. Be aware that scrum master is only as strong as the team, so the primary job of the scrum master is to build a strong, learning team and actively sense and remove impediments that come its way.

2. Proud and Happy Teams - Do you love that? Will you make it your mission to make your teams proud of the work they do and how they do it, so they can predictably meet their commitments to business, deliver quality output keeping technical debt under check? If you answered these questions as yes, you get full marks!

3. Are you looking for glory for yourself or for the team(s) that you will serve? Can you be self-less in victory of your team's success, will you let them take the credit and can you teach them to learn from failures? Will your organization reward you if you served selflessly? Will your manager understand? If your answer to these questions is yes, you have hope.

4. Do you understand Agile manifesto, Agile principles and do you subscribe to XP values of simplicity, communication, feedback, respect and Courage? If you answered yes, think again. If you answered yes again (and again), think about situations that could get you in trouble with stakeholders, management, and even the team that you might be serving. Would you be able to manage expectations and still help the teams succeed? Yes means you are in business!

5. Are you ready to learn, unlearn and learn again? Different situations require different responses and solutions. Are you willing to experiment with different approaches, solutions and options with different team members, different teams, different projects, and different managers? Are you willing to engage with your audience and fail-fast, take responsibility for your team's decisions, actions and results (god or bad, specially bad ones)? Are you willing to be open, positively debate with your team, take responsibility of (poor) team decisions even if you disagreed with the team before the decision was made? Yes indicates you have it in you to be a great scrum master.

6. How does your organization view the role of a scrum master? Does it recognize this function as requiring special skills, training and coaching or is there a tendency that Scrum Master is a side-job that anyone with little time can do? If your organization recognizes the importance of this job, you are in luck and the probability of your success will increase dramatically! If it does not recognize it this way, your hard work, diligence and success will surely influence the organization, do not lose hope.

Bottom line, if you want to be a good Scrum Master, wear your servant-leader hat, be well grounded and open to learn, and experiment your way to success.

Can Agile Principles Help Run Successful Programs?

This article was first published by Scrum Alliance on July 22, 2013.

During the last few years, my view of how programs work has evolved. It has moved from viewing program management as traditional "old-school" handling of multiple projects and product portfolios (dry and boring) to seeing program management as a key to ensuring organization success that aligns the organization with its vision, strategy, and innovation. I think of program management as a crucial tool that makes an organization successful by pointing its entire energy and focus toward its most important initiatives and fulfilling its promise to customers, shareholders, and employees.

Why do organizations need programs?

"Programs are a group of projects managed in a coordinated way to obtain benefits and control not available from managing them individually," according to PMI. What do organizations have to gain by investing in coordinating and controlling multiple projects as a program? This is similar to asking what value program management brings to an organization.

A quick search on Google reveals various links on the topic. An article at chron.com lists the following: comprehensive view, work toward strategic goals, consistency, cost savings. An article at eHow.com lists supervision, organization, budgeting, funding, accountability, and delegation.

Program managers shepherd different teams and projects in the organization toward a common objective. These teams sometimes have different internal priorities, which can impact when and how they deliver their part of the program. Program managers help surface these issues and facilitate much-needed conversation around issues, risks, and mitigation to achieve a higher-level organizational goal (or a set of goals).

Streamlining various lines of work within the organization can translate into several financial and nonfinancial benefits, such as revenue generation through on-time market launches, avoided or reduced opportunity costs, reduced operational costs, higher customer goodwill and revenue retention, transparency, and even better employee engagement.

Simple or complex?

There are many factors that make programs simple or complex to execute, such as:

·         Number of projects

·         Dependencies

·         Size of project teams

·         Resource availability/capacity

·         Prioritization of the initiative

·         Degree to which roles and responsibilities of project teams are well defined

·         Communication flows between project teams that require less coordination

·         Processes followed by project teams

·         Degree of transparency between the teams

·         Silos within the organization

The world of strategic program management is usually complex. Simple programs are hard to find, unless you are a small organization with a tightly knit set of teams and only one or two objectives to work on. The reality is that things start becoming complex even in small or midsized organizations when there are multiple issues at play.

How does complexity impact programs?

As organizations grow in size, they usually spread their operations, increase the number of their product offerings, try to become more cost efficient, and create specialized units for different functional areas (marketing, finance, sales, legal, engineering, technical operations, customer support and service, business intelligence, etc.). This suggests that organizations should pay attention to their most important goals while structuring their programs. That can be difficult, as different functional groups of the organization may be working on multiple priorities that might be competing with each other.

How do Agile principles help in dealing with complexity?

Principles laid down along with the Agile Manifesto can be useful in addressing issues related to complexity of programs. Even though these principles are heavily colored with nuances of software development, they can be applied in addressing issues related to complex program management:

1.     Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.Organizations usually have a strategy that is supposed to convey to its employees what is most important for its success in the coming period. This strategy usually includes what the leadership sees as most valuable to its customers. Organizations that manage successful programs are able to prioritize those programs as per their strategy and focus their energy into those initiatives that are most important to their customers.

2.     We welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage: Just as with software development teams using the Agile process, it is desirable that the rest of the teams are attuned to changing market conditions or new insights (whether external or internal to the organization) that might require the product or a service to take a different direction than initially conceived. If all teams are receptive to change, there is a greater chance that the needs of customers will remain the central focus.

3.     We deliver working software frequently, from every couple of weeks to every couple of months, with a preference for the shorter timescale. Just as Agile software development teams manage their work, such as working on small chunks, it makes sense for program teams to show off their work in short cycles so that the rest of the organization knows how the entire effort is progressing. Examples include iterations on sales and marketing strategy by the sales and marketing teams, iterations on customer communication/rollout planning by relevant teams, iterations on a new product or major functionality by the development teams.

4.     Businesspeople and developers must work together daily throughout the project. There is great value in understanding the business perspective while building software. The same is true for other functional groups within the organization, who may not be as involved in building the software as they are in maintaining it. If the development itself is complicated and there are multiple development teams involved, it becomes even more important to keep everyone aligned with business expectations so that the program progresses in the right direction.

5.     We build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done: All teams involved in a strategic initiative need to be motivated to deliver as per customer needs. If the environment encourages favoritism instead of making decisions based on merit, there are chances that everyone will not give their best to fulfill the goal of the program, likely impacting it adversely.

6.     The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Face-to-face communication impacts teams' effectiveness by helping them build rapport and find solutions to bottlenecks and problems quickly. This is true for programs, even though it is much simpler to institutionalize daily face-to-face communication for a co-located team of five to seven people who are working on a single objective. While this is true, program teams should synchronize as often as they can and use technology to fill the gaps if they are not co-located.

7.     Working software is the primary measure of progress. This principle is most useful in complicated projects involving multiple software development teams. Even when other nondevelopment teams are involved in a program, software development is often on the critical path, and that is often where most of the costs are incurred. So it makes sense to measure and track the progress made on working software. Likewise, program teams should measure and track progress of other non-software development deliverables that are required for readiness to deliver the product or service to the end users (launch readiness).

8.     Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. From the program management perspective, all teams should maintain and deliver at a pace based on the work needed to satisfy the program objective. In many situations, one team might start its work after another team has delivered. For example, the team in charge of invoicing may only be able to update the boilerplate of a product after that product is ready and the legal team has delivered the boilerplate to them. Dependencies such as this need to be tackled by program managers, along with the teams, when planning cross-team programs. When program management is sustainable, dependencies surface regularly and are addressed routinely -- kind of like the way it works within a small Scrum team, where those dependencies surface and are resolved on a daily basis.

9.     Continuous attention to technical excellence and good design enhances agility. There is a balance between doing the right things and doing things right. When in a rush, teams may be tempted to cut corners in order to deliver on time. Sometimes this tendency might be driven by a business need that cannot be overruled, and teams are forced to take shortcuts. When this happens, teams must identify and track this as debt that they need to repay at a later stage (sooner is better, as with any debt that incurs an interest cost). Repaying debt regularly and doing things right ensures that the team does not slow down (or become bankrupt!).

10.  Simplicity -- the art of maximizing the amount of work not done -- is essential. Even in case of complex programs, organizations should strive for simplicity. Transparency and visibility are needed in order to create simplicity and maintain the flow of work between teams.

11.  The best architectures, requirements, and designs emerge from self-organizing teams. Agile encourages self-organization, which can be useful when managing programs. For multiple teams, this starts to happen when the each team is considered a unit and the overarching program team is considered the team that needs to reorganize. This is a question of mind-set and is in some ways easier to understand in case of small teams. When multiple teams are involved and each of them has slightly different (at times divergent) goals, self-organization can be difficult to achieve. That is where transparency, prioritization, and visibility of organizational objectives to all teams are useful.

12.  At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Inspecting and adapting at regular intervals is necessary to re-enforce good practices and make improvements. Agile encourages teams to practice self-sustained introspection and retrospectives. This is an important tool for program teams to review and use to fine-tune their practices for long-term success.

Summary

Agile principles, though exhibiting an overlay of software development influences, can be valuable for managing programs involving multiple teams from diverse functional groups.

Goldtaking Notes - Sustainable Pace, Agile India 2012

Here are the audience notes from the GoldTaking Exercise done at Agile India 2012 during the session on "Slowing down to speed up: Encouraging sustainable pace in teams" on 19-Feb-2012.

Final slides are here.

Video from the session:

Group 1: How to motivate team to deliver at sustainable pace

1. Acknowledge the achievements
2. Environment, open culture, celebrate success
3. When things go wrong, personal attacks should be avoided. Learn to internalize and change
4. Celebrate with connection to purpose of work
5. Try adn figure out why team is demoralized and plug the issues
6. Understand the mindset of individuals to understand their de-motivators or motivators. It is possible that coaching will vary from person to person
7. Make team members feel safe and secure to out of demotivation
8. It is good to make mistakes but learn from them. Difference between personal and professional.
9. Over-pampering should be avoided. Put up facts, and be straight-forward
10. Like volleyball, coach should ask for timeouts if required
11.  Practice and preach respect between team members, gain trust
12. Challenge team on collective ownership
13. Team building

Group 2: Tackling Management Interference at Sprint Planning

1. Do not over-commit
2. Rely on velocity and capacity for committing work
3. Scrum Master should facilitate planning and protect team
4. There can be client interference causing pressure on management
5. There is need to adopt new work culture of Agile
6. Lack of clear acceptance criteria upfront during planning
7. Make sure all the stakeholders attend the sprint planning meeting
8. Re-prioritizing of Product backlog by PMs causes disruptions
9. Lack of trust: PM should not commit on behalf of the team at/outside Sprint Planning
10. Development overflows beyond one sprint
1. Plan in a way that this does not happen
2. Estimate for less, specially when team members are shared
11. (Only as much as possible) Accurately estimate/predict the team velocity to know the number of points to take this current sprint
12. Under-commit but over-achieve
13. What should happen if more points need to be delivered to client than what the team can deliver?
1. If the team cannot deliver the points, then team should say "no"

Group 3: Motivation

1. Leaders have to trust. Sustainable pace is a good way of building trust
2. Dan Pink -> Motivation
3. Do you buy into the company objective -> Helps motivate people
4. Behavior that is appreciated, gets respected
5. Stretch goals can help people grow fast
6. Individuals knowing how they are contributing to the bigger picture
7. Exposure to customers: Know about Customer's needs and vision
8. If team values opinion you feel you matter, need to be noticed
9. Appreciation of individuals from external sources over appreciation of teams may demotivate others on the team
1. If the recipient appreciates the team that may help
10. Team finds ways to appreciate/motivate high performers so perhaps no external appreciations needed!?
11. Transparency at all levels is a pre-requisite for motivation
12. Recognize team contribution

Group 4: Ad-Hoc to sustainable pace

1. Experience: Last minute checkins, Slack and work inflow reduction after release
2. Burned down before release, then next sprint gets off to slow-start
3. Why this big-effort before the release? May be things were not really done!
4. Expectations to go faster than you really can go, causes the problem
5. Management push
1. Educate Manager? No, that addresses just one problem
2. You are actually not done if that happens
3. Provide dates to managers that shows the real pace and use that as a basis for planning
6. Improve effectiveness
1. Non-value added requirements, for example paperwork. Have someone else do it - hire a clerk!
2. Identify activities that are taking time and see if they can be reduced to save time
3. Use CI and increased automation to release more often
7. Use scrum prioritization to make hard and real prioritization
8. Avoid "Goldplating" - over-engineering
9. Zero defects to make sure it is really done
10. Piling up work to test at the end of sprint is risky
11. Argument about ability to swarm around stories. Some have seen it happen, some have not
12. Positive experience with testers collaborating with developers (pair) from start. Done=> All test cases targeted => Done
13. How much time to finish a story? 3 days on average, some have minimum 3 days of dev. effort.
14. Tester writes test cases. Developers start developing at the same time they get the test cases

Agile India 2012: Slowing down to Speed up: Encouraging sustainable pace in teams

Agile India 2012: Slowing down to Speed up: Encouraging sustainable pace in teams

Find the final presentation here.

Here is the description:

We would like solutions delivered fast without compromising quality, user experience, implicit requirements and non-functional aspects such as scalability and performance. This would have been easier, if we had all the time in the universe. Doing this in a sustainable manner becomes a huge challenge for teams as there are multiple competing forces at play and because software development is very complex.
Coaches & Practitioners, participate in this workshop and leave with thoughts that will help your teams adopt and practice sustainable pace, and delight your customers over and over again.

Process/Mechanics

Introduction to the topic, understanding participant expectations - 10 minutes
Achieving sustainable pace - 20 minutes
Workshop briefing and topic selection - 10 minutes : Participants will propose and select topics for deeper discussions Workshop - 30 minutes : Goldtaking (The “Goldtaking” format was introduced by Jan-Erik Sandberg and Lars Skaar at Agile2008 and is a variation of the open space format)
Workshop debrief and discussion - 20 minutes

Learning outcomes

In a highly competitive world, delighting customers is no longer optional. Steve Denning, in his book “The Leader’s Guide to Radical Management”), mentions that the goal of an organization is “Customer Delight”, as opposed to making money for its shareholders. Going by this goal in mind, we will examine how we can use Agile as a means to make our teams and organizations successful.

During this workshop, we will explore:

• Sustainable pace - Importance and challenges:
• How does it result in customer delight?
• How agile values are challenged without sustainable pace?
• What prevents us in delivering at a sustainable pace? (such as competitive surroundings, culture, organization structure, conflicting priorities, old habits, antiquated tools, technical debt)
• How can we coach teams towards sustainable pace?:
• Self realization
• Importance of contextual information
• Understanding and responding to Force fields
• Challenging status quo: Stakeholder alignment and participation
• Building your team into Agile craftsmen, and not Agile mechanics
• Using Data as a vehicle for change
• Inspecting and adapting
• Continued engagement

Agile Coaching and Mentoring: Agile India 2012

Submissions to the stage can be made by creating an account at:
http://submit2012india.agilealliance.org/

“As Agile becomes main-stream, the values laid down by the Agile Manifesto are continuously challenged in different ways during its adoption in different situations. Great coaches help teams and organizations in facing and overcoming these challenges through various learning techniques, so that the issues can be handled effectively. Coaches help teams and organizations embrace agile in its true spirit in order to maximize value that is delivered to the customer.

The Coaching stage presents sessions for people who want to help teams become better at agile software development. We are seeking interactive sessions that explore practical techniques a coach can use with teams. We also want to hear stories from experienced coaches that sharing insights into what works and what to avoid.

As an agile coach and mentor, you will learn about skills and techniques needed to improve team effectiveness so that you can guide your teams towards unleashing their true potential. As an agile team member, you will get a better understanding of different perspectives and techniques for improving team dynamics and create a better work environment. This stage will have multiple sessions, potentially including experience reports, tutorials, talks, workshops and research papers. Through these sessions Coaches, Mentors, Leaders and Team members will enhance their existing toolset and return with real life examples and thought leadership in this area. With these insights, they will be in a better position to apply this knowledge and get great results for their situation.

This stage will cover the following:
• Coaching and Mentoring skills and techniques
• Coaching challenges with people and technology
• Helping teams discover and deal with team dysfunctions
• Coaching in different situations (product development, IT services, consulting, distributed teams, new and mature teams, large and small teams etc.)
• Coaching for the enterprise

Come and learn techniques, listen to the experience of other coaches, and see how you can better support teams in their Agile journey.”
================================
Coaches Corner
A space for conference participants to freely interact and mingle with Coaches. We will invite Coaches to sign up for this before and at the conference and coordinate with the Open Jam stage.
================================
Opportunities to contribute:
- Contributing to Coaches Corner (sign up to be a coach on call or when convenient during the event)
- Help the stage evolve (by signing up to update your ideas on the Titan Pad created for the stage: http://agile2012india.titanpad.com/2 )
- Submitting for the stage (http://submit2012india.agilealliance.org/)
- If you would like to be a reviewer, let me know

Agile or Waterfall? That is the question

Are you and your team ready for the changes that agile brings?

Visit the APLN Houston Website for the presentation and a "sample Agile Decision matrix" on this topic. Teams new to Agile and Scrum might find this useful. Note that this is just a starting point - it is beneficial to customize the matrix.

Gave this presentation with Prashant Patel on Nov 18th, 2010.
Thanks to the APLN Houston leadership for organizing the event.

Breaking Scrum: Scope changes within the sprint...

A discussion I started on Linked:

Breaking Scrum: Scope changes within the sprint...
Hi,
Looking a "list of reasons" on why product-owner-pushed scope change during the sprint breaks scrum...

Few I can think of (please add):
- Takes away the focus from the current functionality
- Reduces team ownership
- Impacts Quality
- Impacts Velocity
- Impacts sustenance of Scrum
- .......

Thanks!
Rahul

3 months ago

Prasanna Raghavendra • The basic essense of agile to me is getting joy in the journey (see here: http://2srp.blogspot.com/2010/06/joy-of-journey.html). One should be successful in the small steps to make sure there is continuous passion and teaming, If this fails, everything breaks!

Mike Caddell • A scope change during a sprint - which is a contradiction in terms - invalidates the fundamental agreement and commitment that bounds a Scrum iteration. The team commits to complete a set of functionality as prioritized by the Product Owner and agreed to by the team. The Product Owner in turn commits to helping define and elaborate the agreed on scope in a timely manner to enable the team to do it's work; and only the agreed on scope, nothing else unless the team finishes early and then picks the next highest priority Release Backlog item.

If the team is asked/required to accomplish a different scope of work during the sprint, the mutual commitment to the previously agreed to scope is thus invalidated. At this point, the sprint should be terminated and a new sprint with the new scope begun - starting with Backlog Grooming and Sprint Planning.

Julie Hendry • I agree Mike, although it often depends on what is meant by 'scope change' - is is the overall deliverable or is it simply that we discover more detail?

I've seen successful teams accept some changes within scrum as long as the changes are agree and communicated, and do not change the underlying goal of that sprint.

Rahul Sawhney • Thanks all for comments.
@Julie, To clarify I mean "goal changing" and "deliverable changing" sort of changes. I do not mean discovery of some more details.

Mike Caddell • @Julie - a great clarification!

I meant as Rahul indicates, a change in the objective or the actual content.

As this discussion clearly illustrates conversation almost always illuminates more detail - which is why we value Individuals and Interactions more than Process and Tools!

Derek Neighbors • Is the reason why they do? or the reason why they shouldn't be allowed to?

The reason they do... the team allows them. The don't enforce some penalty in breaking the contract.

The reason they shouldn't be allowed to. A key premise of agile resolves around trust. Changing course mid sprint breaks trust and deteriorates the relationship.

Prasanna Raghavendra • I am seeing this discussion going similar to building a stringent chinese wall between the product owners and the team and closing doors on genuine yet possible changes within iterations. Like I mentioned earlier (brewity killed clarity in my earlier note, I guess!), the focus should be on small but quick win at the end every iteration for the entire team (including product owners). That would mean there should be constant communication and acceptability of what can be done for the changes coming-in while appreciating concerns from both end. A "genuine" change coming in within an iteration should be discussed and accepted when possible while showcasing what it means for the dev teams to pick it up. This is when teaming and binding becomes stronger. Product owners should also have strong reasons why the change envisaged cannot wait until the next iteration.

I would discourage a generic and rigid process coming in the way of teaming. Agile is not a process but it is a set of natural tendancies teams follow to bond, and that should take precendence. it is interesting to note that we are losing our this natural behaviour and find it hard to let those take precendence.

Rahul Sawhney • @Prassana - I agree with you completely.

Just to bring the discussion back towards my question, refining it a bit....
What are the after-effects (short term and long term) of having the "sprint-goal changing" scope changes, which would take the focus away from the team to deliver what they committed?

So far, we have seen some points indicated above, would like to learn more perspectives, experiences when this happened etc..

Jeff Smathers, CSM • Rahul, If I understand your question, I think that Derek and Mike have great answers. I will try to summarize for my own benefit. If the scope change is so large it changes the sprint goal then the team cannot meet its commitments and the sprint is no longer valid and should be ended. A new sprint needs to be planned and started to address the changes. Depending on the maturity of the team, the trust between members and the quality of their relationships could suffer. Keeping to the commitments defined by the sprint goal is very important.

Jason Little • I wouldn't worry so much about the after-effects as I would in trying to figure out why the scope keeps changing every sprint.

Some context would be helpful. Is this team supporting an existing product? Are the interruptions due to customer complaints or support issues? If so, Scrum doesn't work well in that situation.

Is the PO having problems grooming the backlog to get stuff ready for the sprint? Is there a lack of overall product direction? Are different stakeholders pushing conflicting priorities?

A sprint being constantly interrupted is often the symptom of a deeper problem. Focusing on Scrum as dogma isn't going to solve the problem and you'll end up creating more dysfunction and trust issues between the team and the PO.

John Clifford • In Scrum, the team's commitment to accomplish the items on the sprint backlog that starts the sprint is matched by the Product Owner's commitment to observe and respect that commitment by not trying to change the agreed-upon scope for the duration of the sprint. One can't work without the other. I would argue that a Product Owner who continually wants to change scope during the sprint isn't following the Scrum process and doesn't respect the team or their commitment. In my experience, this happens because the Product Owner fails to take ownership of the product backlog; either he procrastinates on prioritization until the last moment and then overlooks stakeholder commitments that drive prioritization needs, and/or fails to take responsibility for ensuring backlog items are groomed and prepared prior to sprint planning.

Not having objective, quantitative, and binary acceptance criteria for sprint backlog items is one of the problems leading to scope change; if the team has no defined criteria for the complete story then what is to stop the Product Owner from whipsawing them around? Therefore, the Product Owner should ensure that sufficiently-defined acceptance criteria exists for all stories that she will bring to the sprint planning meeting... and the team should refuse to consider any item lacking this. This isn't to say that the team and the Product Owner should be at each others' throats, but instead to say the team may need to spend some time during the sprint planning meeting working with the Product Owner to create sufficiently-defined acceptance criteria.

(Product backlog items with valid acceptance criteria and that have been estimated are often referred to as 'Ready-Ready', in the way that sprint backlog items that are completed according to the Definition of Done and all acceptance criteria are referred to as 'Done-Done-Done-Done.' Effective Product Owners always have at least one sprint's worth of backlog items in a 'Ready-Ready' state before the start of a sprint planning meeting.)

I'm a huge believer in not hiding dysfunction, because you can't fix it if you refuse to see it. In the above situation, the sprint planning meeting timebox will most likely end with only one or two items that have valid acceptance criteria; so be it. The Product Owner will need to accept that bandwidth may need to be reserved during the sprint to work on additional items' acceptance criteria in order to be ready for the next sprint; if the team finishes with the committed items early, they can either drag additional items into the sprint or end the sprint early and re-plan/re-launch. At any rate, this should be discussed at the sprint retrospective and a solution devised that will prevent this from happening again should be implemented.

As others have mentioned, if the team believes that an item's scope has changed to the extent that the original commitment is invalidated, then they have the authority to reject the changes and not complete the item... and this should be discussed at the retrospective. Or, if the Product Owner really wants to change scope, e.g., substitute a new sprint backlog item for an existing one, even if the item estimates are identical, then the team has the authority to accept or reject the change, to the extent of cancelling the sprint and re-planning. Again, to expose dysfunction, I counsel against accepting ANY sprint backlog changes, not to be a jerk or uncooperative, but in order to force the issue to the surface... Product Owners who continually fail to prioritize and want another bite at the apple, for whatever reason, are a common issue.

Andy Dent • A few thoughts on this, against a background of multiple scrum teams collaborating internationally, spanning 24 hour time differences. We have architectural separation of much of the work but that translates into one team having the other two as customers.

We could take the bloody-minded approach of just saying "no" but that risks some bugs being blockers to another team for an entire sprint.

An alternative is for the team to identify one or two people as responders to handle urgent cross-team requests. They can have a task allocated in the sprint which is basically a budget of their time, to be whittled down over the course of the sprint and leaving them free to do other tasks of moderate size.

When it comes to tasks being inserted into the sprint, another pet idea of mine is to mandate that tasks with twice the number of story points have to be removed.

This reflects the loss of velocity from something unplanned being included and emphasises the seriousness of the interruption to the product owner. I'd love to know if anyone applies this, how they get on!

Raul Xavier Neto • I´ve got a little intrigued with that many arguments being so dogmatic about scrum. I think that one of the best points of agile (in this case, scrum) is to help teams cope with change. Change that is a big reality on every software project.

I´ll go with Jason and Prasanna telling you that the best thing for your team is to find out why the owner is changing that much and try to bring him to the team, where those changes should be agreed by the team with good discussion.

Speaking of dogmas, maybe the initial phase is too dark in the owner´s head, maybe the team is not sure about the concept or something else. To ease that kind of thing, that usually comes in the beginning of the project, you can try to reduce the sprint duration, bring the owner closer to the team, try different approaches to put the team as one peace. Scrum is not a Religion, it only guides teams to achieve good results, but the principles are the important thing, not the "rules". If you have to, adjust the "rules" to your needs.

Prasanna Raghavendra • @ Raul, @Jason: Bingo!

@Rahul: It is less about worrying about after effects than accepting it as another pragmatic anamoly and see why it occurs and how it can be fixed.

Rahul Sawhney • Thanks John - I enjoyed reading what you have written here.
Thanks to everyone else too - great insight!

Cuan Mulligan • @Rahul, the impact for me is one of cost.

for example, lets say the PO has aprpoval to spend $x on the delivery of a project. It is the role of the PO to ensure the best spend of the companies money.

If the PO keeps changing their mind, this will consume time (cost) and reduce the teams ability to deliver the project benifit for the agreed amount of money.

If the changes are small , ie refeinments, then this should not be an issue. However I have worked with PO, who make quite dramatic changes during a sprint, and then wonder why the project did not deliver. The upside was that they learnt a valuable lesson, and stopped this behaviour.

Gail E. Harris • The fundamental question in this discussion thread is about product-owner driven scope changes during a sprint breaking Scrum. Well, as someone else wrote, Agile approaches like Scrum are all about being agile, and, as it turns out, changing the scope during the sprint doesn't break Scrum at all.

In Ken Schwaber's book "Agile Project Management with Scrum" he describes exactly how to handle this. He says that "management could abnormally terminate the Sprint" at which point there would be a new Sprint planning meeting. Ken further notes that this new planning meeting would make the action highly visible and thus hopefully product owners would not make a habit of it.

It's also worthwhile to note that a new opportunity to change the scope is never more than four weeks away. Once they realize this many product owner's find that four weeks from now is more than soon enough.

Griffin Jones • We have a very small team, working in a start-up.
Priorities change.

When targets-of-opportunity appear, ownership will pause the sprint as we deal with the new higher priority. The owner makes the informed choice.

Long pauses force a clean re-plan of the sprint. Too much switching reduces velocity. But the owner values responsiveness from development, and is willing to accept reduced velocity in exchange.

Rahul Sawhney • @Cuan,Gail and Griffin, Thanks I was looking for exactly these inputs!

I do believe that this does not break Scrum as a framework. When Scrum is done incorrectly, (i.e. when PO makes significant changes without agreeing with the team and does not allow terminating or pausing the sprint, and does so regularly), the team gets demotivated and starts falling apart. And as Cuan mentioned, not learning from experience escalates costs and reduces team's ability to deliver and impacts collaboration.