Multiple team retrospective

This is an adapted retrospective format to suit retrospecting within teams and cross teams in environments where multiple teams work on the same or integrated products in close proximity or have shared code.

I have used this type of retrospective in two variations in different companies. It worked fairly well and I'd recommend it when you have multiple teams doing very short (e.g. 1/2 week) iterations when it is important to keep the length short.
The timings below are for 1 week iterations. If you find time is not enough you can increase as appropriate.

You need 1 section per team on your white boards plus a section for joint retro items.
Here is the agenda:

1. Check-in [3 minutes] - this is where everyone is invited to give short feedback about the iteration (e.g. 3 words). I sometimes skip it depending on the context.
2. Previous retro actions review [2 minutes] usually no more than 5-6 items, quick review of any progress made.
3. Work in teams [15-20 minutes]- ask every team to generate their retro items - you can use various options - most commonly I use 'what went well' and 'what can be improved'. Ask teams to vote for their items and bring to the joint board only those items that seem to be cross team. Also ask them to identify maximum of 3 actions.
4. Bring it together [5-10 minutes] - ask a representative from each team to announce their 'went well' items and their actions and also to bring their team's proposed joint items.
5. Based on the number of joint items either discuss all (if 3-4 max) or ask the team to vote and pick the top 3. This could take 2-3 minutes.
6. [10 minutes] Discuss the selected items and identify any cross team actions.
7. Close the retrospective - you could either do a quick heartbeat retro or ask everyone to vote on how good the retro was and perhaps pick a few not so good to give you feedback.

That's all - I hope I'll be able to add pictures soon.

So how complete should API documentation be?

Now, this is a very specific post.

If I do go generic I shall quit writing.

We had an interesting discussion recently or rather a few discussions in different formats regarding api documentation. In this case possibly the only type of documentation to go with the product. The complexity of the decision comes from the fact that the only current api client team works closely with us and does not require comprehensive documentation, however it is anticipated that other teams will have to use the api in the future.

Some people made a point that we should do as much as possible as we go to avoid accruing of technical debt and I was happy to agree with that.

Others said that we need to find out more about what the customer wants before we proceed and therefore as a start we should do nothing.

The consensus was that we can't spend too much time if the business does not agree on it and we can't do absolutely nothing since we have at least one client to use the api.

While that gave us some options the interesting bit I found was outside this discussion or during the follow-up chat.

The real question should be how much each option costs. If we do the documentation as we go we estimate to spend an average of 15 pair minutes per user story and with about 250 stories related to api calls and estimated at least one additional change (once created) per story that would amount to about 125 pair hours or 250 individual hours. It was noted that while coding without testing first these days is rather the norm however api documentation is not exactly in the same category and besides there is a difference in the level of documenting.

So let's look at another option - suppose we only invest about 16 pair hours to automate some minimal api documentation and have a short handover to the api client team of about 5 minutes per developer per user story which amounts to about 30 individual hours or 62 hours all together. The handover is guaranteed to be short due to our api client team members having access to the api source code, all tests and having been involved in most of the initial beta work.

Then with expected number of total api calls of less than 100 we estimated that a technical documentation specialist who begins as soon as we have relatively stable api calls should require no more than 15 days in total to complete a comprehensive documentation which is likely to be better read than what the team will create (due to specialist skills). The assumption is that the tech documentation specialist will use the automatically generated documentation and may require some conversation - estimated at about 10 minutes of developer time per api call. This amounts to a total of about 200 individual hours.

So even though this is based on many assumptions and estimations it is obvious that sometimes the cost of maintaining the change of api documentation manually could be more expensive than getting help from a specialist in that area for relatively short amount of time and otherwise providing a minimum level of technical documentation. Well that might be wrong. Before this conversion I would have always suggested option one but after it I would be happy to evaluate the context and look at all the available options.

How to destroy a successful product - a step by step guide for companies

The ultimate guide to destroying successful products - suitable for both products from acquired companies or your own unwanted products.

Famous IT magazine (requested to remain anonymous): "An irreplaceable manual for your Marketing, Sales and Development senior managers that demonstrates how the impossible becomes possible - you only need to follow the steps."

This guide starts after you have made a decision that the product is no longer required so we would not discuss the reasons why you may want to destroy a successful product. Some steps must be completed in order and this is specified while others can or should be done simultaneously. You can use this guide free of charge however the author assumes no responsibility if your product is still successful after you have followed the suggested procedure- if you have found the product that can survive these steps please get in touch to exchange ideas.

Step 1 is to keep your intentions secret - the only skill required here is to avoid mentioning your true intentions and this may not be that easy because some people are likely to foresee what you're trying to do. A suggestions is to arrange social activities to demonstrate to the product team that there is nothing to worry about. After all, you want to ensure that your customers are still paying while you execute your plan so it is a good idea to demonstrate to the world that all will remain unchanged.

Step 2 is to change the name of the product. This is very important because the old name is part of the success so if you really want to destroy the product you will have to get rid of the name. For example when Ford bought Aston Martin they did not change the name so the luxury cars brand remained a successful product. However if they intended to destroy the brand they would have certainly changed its name.

Step 3 is to stop selling the product the way it has been sold during all these successful years. This is kind of obvious, isn't it? If it does not sell it will quickly and easily become unsuccessful. The trick here is to propose a new way of selling and convince all of the product people that things will be so much better with this new approach.

Step 4 is somewhat related to step 2. Ensure that the teams developing and producing the product spend considerable amount of time working on non-essential features so that the product quickly falls behind its main competitors. Some ideas of what that might be include - re-branding, features that target non-existent markets or fixing issues or parts in older versions that no customer cares about.

Step 5 - within the teams that create and produce this product - create a culture of blame, uncertainty and fear. This will ensure many key team members will resign and the rest will be more willing to do whatever asked for fear of losing their jobs. This steps is incredibly important for two reasons. First losing key members guarantees the product will no longer progress as fast as before and therefore will easily fall behind competitive products. And two - those that remain in the team will be a lot more willing to move on and work products that you asked them to therefore clearing the path to declare this product unsuccessful and stop any funding.

Step 6 - This one is related to 5 but worth a separate point I think. Find ways to get rid of all the key people around the product that have not left yet. Most such people would realize what is going on and leave but some may not. There is plenty of ways to achieve the suggested - just talk to the appropriate department that usually looks after people in your organisation and they'll figure out a workaround of the employment law.

Step 7 - follows step 6. Getting rid of inconvenient people is good but in some cases you will need to replace them. So when hiring new people it is important to get someone to do the job but also someone who will always say "yes" to you and also will help you create the culture of fear and rumors.. The significance of this is that no one will join your company if you tell them that you are about to destroy the product you're hiring them to manage or work on. So therefore keep that to yourself and ensure people that join or take up roles are of the type that is happy to simply follow your orders.

By this point you may already have successfully destroyed the product. However if you have not yet then here's some more ideas.

Step 8 - Move important functions elsewhere. Say for example if you have multiple locations you can easily make it more difficult for this product team to function if you were to remove one of their important functions and place it in a different location. Distributing the teams also helps towards reducing productivity and in your case achieving this is vital for your goal.

Step 9 - Promise anything to customers in order to get yourself into contracts that you know you cannot fulfil. By doing this once or twice it will become obvious to anyone that the product team is definitely unsuccessful and this product is slowly dying.

Step 10 - You are ready for your final move. After one or two unsuccessful deliveries simply prepare and announce a plan for cease of production and support (in case your product has support). You have made it really easy for yourself because at this point everyone already expects it.

Congratulations!

You have managed to destroy your product. You have worked hard and I hope you appreciate this guide. Note that it will work even if you have a very skilled product team - this is the ultimate guide to make them look bad no matter what they do.

Of course there's always a chance that something might not happen as the guide predicts so if you have tried this step by step procedure get in touch and we can exchange ideas to make it better so it serves more people like you.

I hope it works for you ( or rather it doesn't)