Many articles and books that discuss productivity of meetings suggest that a meeting should have both a goal and an agenda as a prerequisite for starting the meeting.
While I am perfectly happy with this rule and I am certain it applies to the majority of meetings I can argue that once in a while there're meetings/discussions for which figuring out a goal would be as good as starting the meeting and having an agenda is almost pointless as the initial agenda is unlikely to be followed once participants discover more about their goal.
For example - think about a meeting with another team to discuss integrating two products or components of a product. The goal could be - to agree on interface for this integration and the agenda could be
1. Introductions
2. Team A (frond end team) presents the information that they believe they need
3. Team B (back end team) evaluates the requirement and suggests a solution
4. Teams generate ideas and discuss options
5. Any actions are reviewed and owners assigned
Easy, right? It is even easier if it is a recurring meeting when the goal is usually well understood and you can refine the agenda to ensure current requirements are met.
Now consider the following scenario - a new requirement is introduced by the business which would mean changes across components and domains and would potentially affect a few or perhaps all teams. Team members voice concerns and suggest a meeting to decide how to proceed. There's numerous concerns some very specific and some too vague.
When faced with similar scenario recently I have decided that the goal to "decide how to proceed" is too vague and I suspected there's several more specific goals that can be more useful but wasn't sure what they are and consulting almost 30 team members about that would in effect mean starting the meeting earlier (and probably making people unhappy that they are being interrupted). Due to my expectation to see many different goals I also thought the agenda will drastically change and depend on which goal is most important.
So I decided to start the meeting by inviting everyone to state their goal and recorded the goals on a white board. I then read all the goals and asked the team to indicate which 3 goals are the most important to them. Finally I counted the votes and identified the 3 goals with most votes. I then suggested that we should spend a fixed amount of time (e.g. 10 minutes) discussing the first goal. At this point I did not really have much of a plan rather than hoping that the team can generate it or else some obvious actions may come out of discussing the top 3 goals.
In this instance the team did have very good suggestions, with very little participation on my side generated the next points on the agenda and with some minimal time managing intervention we managed to complete the meeting on time, do a re-cap at the end that suggested almost 100% of the participants were satisfied with the result.
So here's in summary the approach for the meeting without agenda and vaguely stated goal:
0. Explain to the best of your knowledge why are you having the meeting and state the suggested time slot - e.g. 1hr
1. Explain why there is no goal and ask everyone (best to go around the circle) to state their goal for the meeting
2. Record all the goals on a white board (try grouping where necessary)
3. Read the goals so that everyone can hear them and allow some clarification questions where necessary
4. Ask the team to pick their top 3 goals
5. Count the votes and announce the first goal to discuss
6. Time box the discussion and let/ask the team to make suggestions of how to proceed
From here on the meeting may take different from from what you or the rest of the team expect.
Some tips that will help you:
7. Remember to time box any discussions and ensure they do not overrun
8. Ensure the group is happy with any statements made by individuals rather than changing direction every time a new suggestion is made
9. If the group is big or if people are interrupting each other and fail to progress because of that introduce a talking token (e.g. only the person holding the token can talk and if someone wants to talk should ask for the token)
10. Ensure the meeting ends on time unless everyone agrees to extend it (sometimes this might be more valuable than finishing on time)
11. Before the meeting ends ask for a re-cap so that everyone hears everyone else's position. This might indicate if another meeting like this is required or more specific actions have already been generated and the group is happy to close the discussion.
12. And finally remember that you own the process not the content - trying to participate will damage your ability to time manage, spot actions items or introduce new rules when necessary (e.g. the talking token)
Well I hope the suggestion could be useful if you face similar situations. Good luck :-)
Thursday, 8 December 2011
Friday, 11 November 2011
Quick backlog estimation
One thing that's been really painful in my previous experience is overall backlog estimation. This is often asked for by the business owner as an impact assessment or to try and gain an understanding of roughly how long is a chunk of work going to take.
The issue is when the chunk of work is split into hundreds of smaller chunks of work each of them requiring a fair amount of analysis and design and perhaps UX, etc. in order for the estimate to have any reasonable meaning. Teams often aren't allowed this time while the need for sizing of the chunk of work still remains and could be important to the business.
Over the past few months we have used an approach to fast backlog estimation which combined with follow up prioritization session (I will post about this in another blog post) has resulted in acceptable outcome for both sides. In order for this to work it is useful if your team has achieved good level of common understanding about estimation of requirements and your backlog should contain a list of user stories and (almost unavoidably a list of epics).
Start with User Stories
Prepare by printing all your user stories (I'd print them all and not use any existing index cards) and have a big table available for the session. Ideally ask 2 dev pairs (or may be 3 devs and a QA) to join you. Separate user stories from epics and work with the user stories first. Separate the cards into 2 piles and give each pair of team members one pile. Ask each pair to work in one half of the table so they don't mix cards (for now). Also ask them to put the user stories in groups by size - e.g. in the middle of the table user stories that seem to be about the average size of a typical story (Group A) , at the top user stories that seem much bigger than average (e.g. 2x or 3x) (Group B) and at the bottom user stories that seem very simple (e.g. 1/2 or 1/3 the average) (Group C) . After this phase is done ask the pairs to switch sides of the table and review what the other pair has done and mark any cards that they may not agree with the suggested sizing for discussion. Have the discussions and move the cards as appropriate if that's what team members agree. You can also have a 4th group of cards (Group D) for stories that have so many unknowns that it seems impossible to put into any of the other groups. Once this phase is done make sure to carefully collect your cards in groups so you can update them later on.
Now the epics
Following a similar approach hand each pair about half of your epic cards and ask them to group them in the following groups. For example in the middle of the table - those for which is relatively clear what needs doing but it just seems like a lot to do (Group E) , those that seem relatively small at the bottom of the table (Group F) and those that seem fairly unclear or there are lots of unknowns put at the top (Group G). Again ask the two pairs to work in separate half of the tables and then swap to review their groupings. Once this is done thank the team members for their participation and with all collected cards proceed with updating your actual cards in excel or the electronic tool that you're using.
This should take you between 25 and 40 minutes depending on your backlog size. We have consistently achieved below 30 minutes with backlogs of around 80-150 items.
Getting to numbers
Now this will depend on your specific team estimates. I'll take an example where the average size of a story for you might be 5. Note - any stories estimated by the whole team in your usual estimation workshops leave as they are - you can use them to calculate your story average. For any stories without estimates you can do the following: Assign this to group A cards, to group B cards assign 3 times your average size - which would be 15 or perhaps 13 if you're using Fibonacci numbers. To group C stories assign estimate of 2. To Group D items assign 20s and give to your BA/PO for further analysis - somehow indicate this in your electronic tool. There's two approaches you may want to use for the epics. Either look at them as gaps of missing stories and ask your BA/PO to estimate how many stories approximately (and as a range) s/he thinks they may contain and use the average story size - e.g. Gap A is likely to produce 5-8 stories so I'd use the higher estimate of 8 and multiply it by my average of 5 which means that Gap A will have size of 40 for the time being.
Or if your BA/PO is not comfortable to do this for now use similar approach to stories e.g. - to Group E assign 3 times the group B estimate - e.g. 40, to group F assign the group B estimate - e.g. 13 and to group F items give something like 2x your group E estimate - e.g. 80 or 100.
Backlog size
Now once you've done all the updating your total backlog size will probably look enormous. Obviously the more epics you have the bigger number you'll get. Explain to your BA/PO that the epics need clarifications and that you'd need these resolved, questions answered and sizes refined before having a meaningful backlog size. Your BA is likely to start analyzing all over the place so why not start with these big items alongside any risky items s/he might be looking at. You could also review the remaining unanswered questions and gaps on a weekly basis reiterating that the sooner you refine those estimates the sooner you can get to a realistic size.
Interesting enough having epics in the backlog has not stopped us doing prioritization sessions with business owners - I will explain how in another blog post.
Once you agree that your backlog seems to contain mostly stuff with known size then you can follow standard burn down/up practices to produce that much desired date/range. I'd also monitor historically what is the growth of the size of a backlog and apply that as a buffer because new stories will get produced. Ideally you'd want to have this growth historic figure based on a full release cycle.
So this one has already become bigger than I was hoping it will be. I hope it is useful and makes sense. I will try to take a picture next time we do this and attach it here. All feedback is welcome ;)
The issue is when the chunk of work is split into hundreds of smaller chunks of work each of them requiring a fair amount of analysis and design and perhaps UX, etc. in order for the estimate to have any reasonable meaning. Teams often aren't allowed this time while the need for sizing of the chunk of work still remains and could be important to the business.
Over the past few months we have used an approach to fast backlog estimation which combined with follow up prioritization session (I will post about this in another blog post) has resulted in acceptable outcome for both sides. In order for this to work it is useful if your team has achieved good level of common understanding about estimation of requirements and your backlog should contain a list of user stories and (almost unavoidably a list of epics).
Start with User Stories
Prepare by printing all your user stories (I'd print them all and not use any existing index cards) and have a big table available for the session. Ideally ask 2 dev pairs (or may be 3 devs and a QA) to join you. Separate user stories from epics and work with the user stories first. Separate the cards into 2 piles and give each pair of team members one pile. Ask each pair to work in one half of the table so they don't mix cards (for now). Also ask them to put the user stories in groups by size - e.g. in the middle of the table user stories that seem to be about the average size of a typical story (Group A) , at the top user stories that seem much bigger than average (e.g. 2x or 3x) (Group B) and at the bottom user stories that seem very simple (e.g. 1/2 or 1/3 the average) (Group C) . After this phase is done ask the pairs to switch sides of the table and review what the other pair has done and mark any cards that they may not agree with the suggested sizing for discussion. Have the discussions and move the cards as appropriate if that's what team members agree. You can also have a 4th group of cards (Group D) for stories that have so many unknowns that it seems impossible to put into any of the other groups. Once this phase is done make sure to carefully collect your cards in groups so you can update them later on.
Now the epics
Following a similar approach hand each pair about half of your epic cards and ask them to group them in the following groups. For example in the middle of the table - those for which is relatively clear what needs doing but it just seems like a lot to do (Group E) , those that seem relatively small at the bottom of the table (Group F) and those that seem fairly unclear or there are lots of unknowns put at the top (Group G). Again ask the two pairs to work in separate half of the tables and then swap to review their groupings. Once this is done thank the team members for their participation and with all collected cards proceed with updating your actual cards in excel or the electronic tool that you're using.
This should take you between 25 and 40 minutes depending on your backlog size. We have consistently achieved below 30 minutes with backlogs of around 80-150 items.
Getting to numbers
Now this will depend on your specific team estimates. I'll take an example where the average size of a story for you might be 5. Note - any stories estimated by the whole team in your usual estimation workshops leave as they are - you can use them to calculate your story average. For any stories without estimates you can do the following: Assign this to group A cards, to group B cards assign 3 times your average size - which would be 15 or perhaps 13 if you're using Fibonacci numbers. To group C stories assign estimate of 2. To Group D items assign 20s and give to your BA/PO for further analysis - somehow indicate this in your electronic tool. There's two approaches you may want to use for the epics. Either look at them as gaps of missing stories and ask your BA/PO to estimate how many stories approximately (and as a range) s/he thinks they may contain and use the average story size - e.g. Gap A is likely to produce 5-8 stories so I'd use the higher estimate of 8 and multiply it by my average of 5 which means that Gap A will have size of 40 for the time being.
Or if your BA/PO is not comfortable to do this for now use similar approach to stories e.g. - to Group E assign 3 times the group B estimate - e.g. 40, to group F assign the group B estimate - e.g. 13 and to group F items give something like 2x your group E estimate - e.g. 80 or 100.
Backlog size
Now once you've done all the updating your total backlog size will probably look enormous. Obviously the more epics you have the bigger number you'll get. Explain to your BA/PO that the epics need clarifications and that you'd need these resolved, questions answered and sizes refined before having a meaningful backlog size. Your BA is likely to start analyzing all over the place so why not start with these big items alongside any risky items s/he might be looking at. You could also review the remaining unanswered questions and gaps on a weekly basis reiterating that the sooner you refine those estimates the sooner you can get to a realistic size.
Interesting enough having epics in the backlog has not stopped us doing prioritization sessions with business owners - I will explain how in another blog post.
Once you agree that your backlog seems to contain mostly stuff with known size then you can follow standard burn down/up practices to produce that much desired date/range. I'd also monitor historically what is the growth of the size of a backlog and apply that as a buffer because new stories will get produced. Ideally you'd want to have this growth historic figure based on a full release cycle.
So this one has already become bigger than I was hoping it will be. I hope it is useful and makes sense. I will try to take a picture next time we do this and attach it here. All feedback is welcome ;)
Thursday, 10 November 2011
One week is just right
This goal of this post is to outline some good reasons why one week iterations are a very good idea for most software development teams.
The suggestions and conclusions below are based on my experience with one week iterations across 3 teams on a major e-commerce project.
Before seeing one week iterations in action I believed they could be too stressful and with very little time to prepare requirements or even complete something useful and potentially end up with nothing to demo most of the weeks. I have since changed my opinion based on almost 50 iterations of evidence so let's start with the reasons
1. It is tough! What I thought before turned out to be true! There are so many things that need to happen for a week and yes it is tough. It is tough for the analysts to prepare requirements, meet with QA and refine them, meet with devs and refine them, get answers and slice and descope as necessary. It is tough for the devs to ensure requirements are small enough to develop and meaningful enough to present, reject requirements that aren't ready, estimate and tech design and implement those that are. It is tough for the QAs to participate in acceptance test specification for new requirements, acceptance test writing for those in progress, functional and journey tests, exploration tests and demo preparations. You get it I believe. Yet even though it is tough it is also very useful that it is tough because it is a built-in pressure that ensures people switch on to disciplined mode because to get through all these you have to be disciplined. So reason number one is that the busy schedule increases discipline and discipline is the best friend of competence.
2. There is stuff to demo! - with over 50 iterations of evidence I am confident one week iterations will not impact teams ability to show progress. Quite the opposite, the ability to show something that isn't just working but actually in most cases ready to go into production is the best way to win the customer over and over again. You could say in most companies the stakeholders would be amazed if you are able to deliver quality meaningful features every week.
3. You really are more agile/flexible. Actually seeing the impact of one week iterations I am starting to think that anything more than 2 really isn't much help in terms of flexibility. Shorter cycles let you fail faster and improve faster. They also allow the business to adapt faster and significantly reduce any change concerns. Shorter cycles also enforce good engineering practices like emerging design and architecture, continuous integration and deployment, true shared code ownership and refactoring.
4. These guys are great! Even though I already touched on credibility in point 2 I think it deserves a separate section. Your ability to deliver every week will impress people, especially if you're the first team in the organisation to do such short cycles. Along with your CI tools and your ability to deploy anytime and I am sure these will prompt even more amazing practices and tools it is very likely that you soon will become centre of attention and people would want to associate themselves with your team and even work for you. Granted this may happen without one week iterations but I believe they improve your chances.
5. It is all or nothing. If you've ever heard a business owner saying "they're all must haves really" then you know what I mean. What one week iterations combine well is positive feeling about delivering all the time and a shorter release planning cycle. And in case you're wondering yes I do mean looking at the release plan with the business owner every week or as often as possible but never more than 2 weeks between the sessions. The combination of high business confidence in your ability to deliver with the regular realisation what is possible with the current capacity and what not will virtually ensure the business owner's buy in into fixed date/flexible scope idea. (I would not really want to go for fixed scope/flexible date but that is for another article). And that is one of the most important hurdles to making your release successful simply gone.
So in conclusion - I believe one week iterations are just right. Of course based on the environments that I've seen but also based on feedback from 20+ colleagues about the environments that they've seen.
So I'd say it is a pretty good bet that it would help you if you're thinking about doing shorter cycles. And I hope you won't forget to have fun ;)
The suggestions and conclusions below are based on my experience with one week iterations across 3 teams on a major e-commerce project.
Before seeing one week iterations in action I believed they could be too stressful and with very little time to prepare requirements or even complete something useful and potentially end up with nothing to demo most of the weeks. I have since changed my opinion based on almost 50 iterations of evidence so let's start with the reasons
1. It is tough! What I thought before turned out to be true! There are so many things that need to happen for a week and yes it is tough. It is tough for the analysts to prepare requirements, meet with QA and refine them, meet with devs and refine them, get answers and slice and descope as necessary. It is tough for the devs to ensure requirements are small enough to develop and meaningful enough to present, reject requirements that aren't ready, estimate and tech design and implement those that are. It is tough for the QAs to participate in acceptance test specification for new requirements, acceptance test writing for those in progress, functional and journey tests, exploration tests and demo preparations. You get it I believe. Yet even though it is tough it is also very useful that it is tough because it is a built-in pressure that ensures people switch on to disciplined mode because to get through all these you have to be disciplined. So reason number one is that the busy schedule increases discipline and discipline is the best friend of competence.
2. There is stuff to demo! - with over 50 iterations of evidence I am confident one week iterations will not impact teams ability to show progress. Quite the opposite, the ability to show something that isn't just working but actually in most cases ready to go into production is the best way to win the customer over and over again. You could say in most companies the stakeholders would be amazed if you are able to deliver quality meaningful features every week.
3. You really are more agile/flexible. Actually seeing the impact of one week iterations I am starting to think that anything more than 2 really isn't much help in terms of flexibility. Shorter cycles let you fail faster and improve faster. They also allow the business to adapt faster and significantly reduce any change concerns. Shorter cycles also enforce good engineering practices like emerging design and architecture, continuous integration and deployment, true shared code ownership and refactoring.
4. These guys are great! Even though I already touched on credibility in point 2 I think it deserves a separate section. Your ability to deliver every week will impress people, especially if you're the first team in the organisation to do such short cycles. Along with your CI tools and your ability to deploy anytime and I am sure these will prompt even more amazing practices and tools it is very likely that you soon will become centre of attention and people would want to associate themselves with your team and even work for you. Granted this may happen without one week iterations but I believe they improve your chances.
5. It is all or nothing. If you've ever heard a business owner saying "they're all must haves really" then you know what I mean. What one week iterations combine well is positive feeling about delivering all the time and a shorter release planning cycle. And in case you're wondering yes I do mean looking at the release plan with the business owner every week or as often as possible but never more than 2 weeks between the sessions. The combination of high business confidence in your ability to deliver with the regular realisation what is possible with the current capacity and what not will virtually ensure the business owner's buy in into fixed date/flexible scope idea. (I would not really want to go for fixed scope/flexible date but that is for another article). And that is one of the most important hurdles to making your release successful simply gone.
So in conclusion - I believe one week iterations are just right. Of course based on the environments that I've seen but also based on feedback from 20+ colleagues about the environments that they've seen.
So I'd say it is a pretty good bet that it would help you if you're thinking about doing shorter cycles. And I hope you won't forget to have fun ;)
Monday, 26 September 2011
Futurespective (the way we do it)
Furturespective (also Future-spective) is an approach to run retrospectives or improvement workshops which attempts to drive out possible improvement opportunities (usually to process but can be others) by shifting the group's focus into the future and then looking back from there. It is described well by Anders Laestadius here however this is not exactly the way we do it in my current team. So I decided to write up a summary of the "Furturespective the way we do it":
The agenda is usually something like this :
Check-in - Sometimes, especially if you do it for the first time, the check-in can be your explanation of the concept of the Futurespective which is usually engaging enough to get people's attention
Successful end: Explain that you're now at the end of the project/delivery/release and it is a success so you ask the team to brainstorm the reasons why they аre successful.
When step 2 is over (say 5 minutes) ask everyone to post their items on the board and explain them (and group as much as possible)
Unsuccessful end: Now explain a second scenario - the project is a failure and ask the team to list possible reasons why this might have happened.
Like in step 3 after short brainstorming ask the team to post and explain the generated ideas/reasons.
Now ask the team to vote e.g. 3 votes each or choose more appropriate number based on team size. A variations can be 2 votes per positive item and 3 for negative.
Count the votes and discuss the top 2-3 items (depending on time restrictions)
Discuss the top voted items and try to generate follow up sessions or actions.
Check-out
The agenda is usually something like this :
Hope this is useful. Thanks to @alfie_thomas99 for this version of the futurespective.
Monday, 5 September 2011
So what's new in LeaveWizard land
Together with Rich Allen I have been working on this great app called LeaveWizard for over 2 years now.. And I've never blogged anything about LeaveWizard and it's a shame because I am so passionate about it.. well as you may guess there was a reason not to blog but that reason is now a distant and insignificant past so here comes my first post on LeaveWizard.
What is it?
LeaveWizard is an online based application that helps you organize and manage absence and events for your teams. We have taken an approach that gives you simplicity if you choose not to modify the default options and it also has built in flexibility to support fully customiseable event types including time off in lieu, work patterns that lets you design custom shifts, leave restriction at different levels and custom groups. It even supports simple room booking and the list of features is growing every week.
What is it?
LeaveWizard is an online based application that helps you organize and manage absence and events for your teams. We have taken an approach that gives you simplicity if you choose not to modify the default options and it also has built in flexibility to support fully customiseable event types including time off in lieu, work patterns that lets you design custom shifts, leave restriction at different levels and custom groups. It even supports simple room booking and the list of features is growing every week.
Why did we start it?
We started LeaveWizard because of a common 'leave management' problem we both experienced. We also started it with a desire to build a great application that our customers love to use. The core values that help us progress are simplicity, user feedback and built in quality.
What's new in LeaveWizard land
Now on to the point of this post. Every time we release new features we make them visible through a blog post in our LeaveWizard blog. We also add to our collection of extended help articles to help customers get started with the new features.
Over the past 6 months we have added some really cool features like accrued allowance, new UI which follows an ultra simple pattern to help customers get up to speed and get the job done quickly, events like overtime that can turn into additional allowance, calculation of the bradford factor which is a funny number to have available to you (if you wanted to go that route), support for event type that have allowance in hours and many small enhancements like controlling event types that get published in calendars, visibility of event type allowance and event details, hiding certain users from lists and charts and configuring various options for customers so they can make the most of the application.
One thing we love is to hear feedback and ideas from our customers, which is why we regularly monitor and pick ideas from our feedback forum.
So now I have blogged about it I can start looking at the stuff that's next on our list so I have more reasons to blog about the new cool features next month.
Thursday, 18 August 2011
A year of new beginning, excitement and tons of learning
My year runs to end of August. The time I spend back in my own Bulgaria naturally marks the end and the beginning. And it feels like this is a much better point in time than the one suggested by the calendar.
So here it is again - it is that time of the year. I am off tomorrow and have 10 days to go through my "rebirth" once more. And before I go there's a few things I shall write down to remind me of 2011.
"What a year" are probably the only known 3 words that can fully describe it. While 2010 was a(nother?) year of frustration, ridiculous events at work, lots of sadness to go through with the only real highlight being the visit to India, 2011 brought the new beginning I was so long preparing and longing for, two visits to dream destinations and most important of all - finally - a work place where I no longer have to deal with any of the weirdness and frustration that were built into my days before. LeaveWizard also made a significant step to becoming a success and as time goes by working on the product continues to be a privilege and pleasure.
The significance of the events in 2011 is so immense for me that words cannot describe it well enough. If I achieve the same in the next twelve months I'd be extremely happy. I hope at the very least I do not miss many opportunities to learn and I also hope that together with this amazing team we can build the right product right (or at least get as close to that as possible).
So with that I am off to get a few days break, some sunshine and generally restart. Ta-da.
Wednesday, 20 April 2011
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.
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.
Monday, 18 April 2011
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.
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.
Friday, 15 April 2011
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)
Monday, 21 March 2011
Agile links Collection 2011 vol.2
Well, things got a bit busy in Plamenland and I realized I can't keep up with weekly links so instead will have to collect the links and post when I have enough. On the plus side that means there's a better chance I read some or most of the articles and filter out those which I feel are not good enough to make the list. Anyway - enjoy my second set for 2011 ;)
People x Process - How Facebook Became the Hottest Company on the Planet Warning - This one's long. Worth a read if you have the time - explains a lot about facebook and to my mind provides a good learning opportunity for entrepreneurs.
Great Leaders aren’t Emotional By Dan Rockwell, have not read it. would like to read though - looks insightful to me.
How to Develop Products like Toyota Good article about the main differences between how Toyota and its competitors make products.
What Henry Ford Knew That Many CEOs Have Forgotten A good short read which taught me a lot about Henry Ford
How to plan a workshop Useful guide from John McFadyen
Agile – in name only? If you're into coaching perhaps worth a read..
The Perfect ScrumMaster Job Description I know, I know - another one.. may be you're fed up with it and may be this one is the right one for you?
Complexity versus Lean Jurgen Appelo's talk at LESS2010 conference in Helsinki. I think he got best speaker/presentation award for this.
What is an Agile Scout? – Our Order of Agility and Law This is a good list of activities and characteristics of an agile coach. Not sure why we need a new name though.
Gossip Kills Possibility Dan Pallotta has a wonderful story to tell and he nicely ties it up with business environment. Some plain and true statements about what leadership is all about. Recommended read.
In Response To SCORE A good analysis of an attempt to implement something agile. Pointing out some misjudgements and can be useful when evaluating someone else's process.
People x Process - How Facebook Became the Hottest Company on the Planet Warning - This one's long. Worth a read if you have the time - explains a lot about facebook and to my mind provides a good learning opportunity for entrepreneurs.
Great Leaders aren’t Emotional By Dan Rockwell, have not read it. would like to read though - looks insightful to me.
How to Develop Products like Toyota Good article about the main differences between how Toyota and its competitors make products.
What Henry Ford Knew That Many CEOs Have Forgotten A good short read which taught me a lot about Henry Ford
How to plan a workshop Useful guide from John McFadyen
Agile – in name only? If you're into coaching perhaps worth a read..
The Perfect ScrumMaster Job Description I know, I know - another one.. may be you're fed up with it and may be this one is the right one for you?
Complexity versus Lean Jurgen Appelo's talk at LESS2010 conference in Helsinki. I think he got best speaker/presentation award for this.
What is an Agile Scout? – Our Order of Agility and Law This is a good list of activities and characteristics of an agile coach. Not sure why we need a new name though.
Gossip Kills Possibility Dan Pallotta has a wonderful story to tell and he nicely ties it up with business environment. Some plain and true statements about what leadership is all about. Recommended read.
In Response To SCORE A good analysis of an attempt to implement something agile. Pointing out some misjudgements and can be useful when evaluating someone else's process.
Monday, 31 January 2011
Agile/Scrum Retrospective Meetings - Various or Different formats or plans
This collection is most certainly not uncovering amazing and unheard of ways of doing retrospectives. To be precise Agile Retrospecives has so many activities for the different phases (as defined in the book) that you can mix and match and create many different variations.
If you are on the look out for something quick that has worked elsewhere though I hope that this small list may help you save some time.
First up is a collection of games that I have known for some time although have not tried all of them.
the Retro Wiki http://retrospectivewiki.org/
Next up is a format which is not on the Retro wiki and I have done in several enironments and I have also recommended to a friend who has done it and the feedback was good.
The cool wall Retro
Tasty cupcakes was recommended to me although I was not able to find any games suitable for retros on there. Perhaps some can be adapted or activities used in other types of games could be borrowed and used in a retro. Useful site to have in the bookmarks anyway.
Multi team retrospective - this is a format I have used in two variations in different companies. Works fairly well and I'd recommend it when you have multiple teams doing very short (e.g. 1 week) iterations when it is important to keep the length short. I explain it here.
How We Do a Retrospective - Tim Wingfield explains how his team does retrospective. Looks a good approach to try, certainly slightly different combination of ideas compared to what I've seen before.
If you are on the look out for something quick that has worked elsewhere though I hope that this small list may help you save some time.
First up is a collection of games that I have known for some time although have not tried all of them.
the Retro Wiki http://retrospectivewiki.org/
Next up is a format which is not on the Retro wiki and I have done in several enironments and I have also recommended to a friend who has done it and the feedback was good.
The cool wall Retro
Tasty cupcakes was recommended to me although I was not able to find any games suitable for retros on there. Perhaps some can be adapted or activities used in other types of games could be borrowed and used in a retro. Useful site to have in the bookmarks anyway.
Multi team retrospective - this is a format I have used in two variations in different companies. Works fairly well and I'd recommend it when you have multiple teams doing very short (e.g. 1 week) iterations when it is important to keep the length short. I explain it here.
How We Do a Retrospective - Tim Wingfield explains how his team does retrospective. Looks a good approach to try, certainly slightly different combination of ideas compared to what I've seen before.
[Added in Sept 2011]
Furturespective (also Future-spective) is a way of driving possible improvement opportunities by shifting your focus into the future and then looking back from there. It is described well by Anders Laestadius here and also mentioned by PierG here however it is not exactly the way we do it in my current project. So I decided to write up a summary of the "Furturespective the way we do it" here.
Agile Links - first set for 2011
I have now missed so many weeks so there really is no point to call it weekly is there?
My collection though I believe has some very good reads in it!
How to Create Change: Don’t Help People A nice view on how to instigate change. I like the beginning of it, hopefully some day I'll read it all.
What about Chris Argyris? Luc Galoppin has written a fantastic brief on Argyris and to be honest if I had read that before I might have skipped reading those books ;)
Don’t Prioritize Features! Scott Sehlhorst claims prioritising features is a waste of time. I tend to agree with him (to an extent).
Per-Feature ROI Is (Usually) a Stupid Waste of Time Here's another view that is slightly different from most people's understanding from reading all those agile books. I like the reasoning though.
Single Piece Flow in Kanban: A How-To A video presentation by James Shore and Arlo Belshee
Tightening the Feedback Loop You can never go wrong watching Patt Kua's presentations and this one is very important - very much related to double loop.
Business-Driven EnterpriseAgility A video by net objectives (A.Shalloway and co.)
My collection though I believe has some very good reads in it!
How to Create Change: Don’t Help People A nice view on how to instigate change. I like the beginning of it, hopefully some day I'll read it all.
What about Chris Argyris? Luc Galoppin has written a fantastic brief on Argyris and to be honest if I had read that before I might have skipped reading those books ;)
Don’t Prioritize Features! Scott Sehlhorst claims prioritising features is a waste of time. I tend to agree with him (to an extent).
Per-Feature ROI Is (Usually) a Stupid Waste of Time Here's another view that is slightly different from most people's understanding from reading all those agile books. I like the reasoning though.
Single Piece Flow in Kanban: A How-To A video presentation by James Shore and Arlo Belshee
Tightening the Feedback Loop You can never go wrong watching Patt Kua's presentations and this one is very important - very much related to double loop.
Business-Driven EnterpriseAgility A video by net objectives (A.Shalloway and co.)
Subscribe to:
Posts (Atom)