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!

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

Seamless Integration of Web Services (old article)

While simply browsing I came across this article on the net, which was written jointly by George Chiramattel, Brijesh Chenan and me, many years ago (in 2002 or 2003). It won us the Microsoft India Road Ahead Contest. I am very happy to find it again and put it back. It is good to see that a lot of what we said in this article has actually happened after we wrote this...

Introduction

Today we are witnessing another era of explosive growth on the web. The web has come a long way, from static content to dynamic content and now to programmable web services. The Internet has metamorphosed into a pervasive computing domain, providing value-added services. This means that the web is now available in ways never imagined in the past.
While embarking on a web services approach, several important questions come to mind.

• How can we make it easier for our customers to use our web services?
• How can we increase our client base?
• How can we ensure a viable business model around our web services?
• How can we make our applications more powerful by harnessing the power of web services?
• How can we provide our customers access to web services that are “yet to be developed”?
• How can we ensure that our applications are state of the art and provide the latest features without massive development costs?

These applications will be able to utilize the zillions of services out there and the ones that are yet to come. Armed with the knowledge of web services, they will be able to proactively help users in getting their work done. As developers we should focus not only on exposing services but also be capable of locating and binding to existing and future services on the net.

• Mapping between data and web methods
• Mapping between common action and web service methods

The web is now mature enough in terms of availability of services. All the functionality that you would want is probably already there on the web. But the truth is that only a knowledge worker can harness the full power of the programmable web. Further there is no integration of web services into applications that people use daily. It is time to start thinking about bringing this power to the common man.

This paper proposes some enhancements to the existing web services framework for better integration between web services and applications accessing them.

Need for Seamless Integration

As web service providers,

As application developers,

The answers to these questions lead us to the next generation of killer applications.

To illustrate, let’s look at the following scenario.

Scenario

Suppose you are interested in online trading and would like to check out the top-ten movers. Further, you might also want to transact on them. In today’s world, typically you would use your browser to search the web for online stock trading services. You would then choose one of these services and then navigate to its site. Here, you would click the link for the top-ten movers. In the list returned, you find MSFT [Symbol for Microsoft Corporation stock at NASDAQ] interesting and want to buy 100 shares. To do this, you would click the corresponding link on the site and make the transaction. Now, suppose you want more information about MSFT from some other service, or make the trade elsewhere, you would have to perform the same operations all over again at the second site. You obviously cannot use the data you obtained from the first site to invoke services at the second site.

Let us see how the killer applications of tomorrow alter this scenario. You fire up the next generation Excel and run a web query on the top-ten movers. The web query returns the results from the web service and formats it on screen. You find MSFT interesting, so you right click on the symbol ‘MSFT’. The context menu shows you the option “Web Actions -> Get Detailed Stock Quote…”. When you click this option, it returns the latest stock quote update on MSFT. You then decide to buy 100 shares, so you right click and select “Web Actions à Buy this stock…” on the context menu and go on to complete the transaction (See figure below).

Using Excel, you query your portfolio (probably from another web service) and see your open positions. You see that you are long on ‘MSFT’ and decide to sell 50. You go to the corresponding field and edit it to 50. Excel automatically prompts you “Do you want to sell?” You press “Yes” to complete the transaction.

How to realize this

This can be achieved through a combination of two enhancements to current web services framework.

Mapping between data and web methods

The WSDL [Web Service Description Language] file provides the application with an interface description of that web service. Each of these web methods returns XML data. With the current standards, it is not possible for the application to figure out what further can be done on these data. The application will have to rely on custom hard-coded logic to invoke further actions on the data. If we have another XML file that will contain the mapping between the data elements and what actions can be invoked on them, the application can be much more proactive in helping the user get the work done. These actions relate to other web-service methods, which could be provided by either the same or some other web-service provider.

In short we propose to provide a link to an XML file within the WSDL file for a web-service. Bodies such as W3C [World Wide Web Consortium] can standardize the schema for this XML file.

With this in place, the application in the illustrated Scenario will be able to provide context actions like “Get Latest Stock Quote” and “Buy this stock” because it automatically knows what can be done with the data.

We feel that the concept of associating web services and data is very powerful. It opens up new avenues for applications to interact with multiple web services on behalf of the user without him having to write any programming logic.

Mapping between common actions and web service methods

We have seen how the mapping between data and actions will enable the user to invoke services for that data. But the user has to initiate this action, probably through a context menu. We can take this to the next level by making our applications intelligent so as to invoke corresponding services automatically.

In the above Scenario, when the user modified the field containing the number of stocks in his portfolio, Excel understood that the user is doing an ‘Edit’ action on that data item (which was returned by a web service). It is now up to Excel to find out which method corresponds to the ‘Edit’ action for the data item being edited. Once this method is identified, consent from the user is obtained to invoke it on the server to make the transaction.

A standardizing body can define an XML file that lists certain commonly performed actions (e.g. verbs like edit and delete). Next generation applications should be aware of these verbs defined in this XML file and be able to translate user-actions to them. A service provider while publishing the service can also provide a mapping XML file. This file specifies the verbs associated with data that is returned from each web method. In turn, each verb is mapped to a web method that is invoked when the user performs the corresponding action at the application side. The schema for this file should also be standardized.

Conclusion

The Internet will continue to evolve as a source of computational services rather than a repository of content. The web will gradually move towards a state where more and more value-added services will be presented as web services. The killer applications of tomorrow will be the ones that can seamlessly integrate these web services. These applications will replace the browser as the main interaction point to the web and blur the boundary between the local and the remote.

The standards of today focus more on how to locate, identify and bind to services. We should also focus on standards that define consumption of these services. This will allow applications to behave intelligently to identify and invoke services from disparate sources, transparent to the user.