Plamen's Blog

The meeting without agenda

2011-12-08T07:30:00.000Z

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 :-)

Quick backlog estimation

2011-11-11T07:11:00.000Z

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 ;)

One week is just right

2011-11-10T07:00:00.000Z

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 ;)

Futurespective (the way we do it)

2011-09-26T18:51:00.007+01:00

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

Hope this is useful. Thanks to @alfie_thomas99 for this version of the futurespective.

So what's new in LeaveWizard land

2011-09-05T23:46:00.011+01:00

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.

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.

A year of new beginning, excitement and tons of learning

2011-08-18T22:19:00.001+01:00

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.

Multiple team retrospective

2011-04-20T22:31:00.003+01:00

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?

2011-04-18T22:44:00.002+01:00

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

2011-04-15T12:14:00.016+01:00

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)

Agile links Collection 2011 vol.2

2011-03-21T11:40:00.000Z

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.

Agile/Scrum Retrospective Meetings - Various or Different formats or plans

2011-01-31T11:00:00.009Z

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.

[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

2011-01-31T10:43:00.007Z

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.)

Agile Links - last set for 2010

2010-12-30T15:20:00.002Z

Just realised the number of open tabs is far beyond the number of articles I may read in the next few days so thought I should still save them somewhere before closing them (they eat up my memory, no?). so that defo is the last post for 2010 - enjoy - most are good reads ;)

To deliver the project at hand, or deliver improved project-delivering capability for the future? by Bob Marshal

The Definition of Ready by Roman Pichler

Assange, Argyris and Aristotle
by LORNE MITCHELL

How to Fix Misunderstandings at Work and in Life by Dan Pallotta

ACHIEVING AGILITY: MEANS TO AN END, OR END IN ITSELF
By Esther Derby

Fourth Generation Management: Brian L. Joiner. Book Review by Stephen Parry

Happy New Year ;)

A new era

2010-12-13T18:13:00.004Z

As you read these words our world is undergoing a major change. No surprise I guess- it has been for centuries. The significant change this time is in our minds and it is affecting many areas of our life.

We are becoming more and more aware of our behaviour and how it affects the results of our efforts. Organisations are becoming increasingly aware of how individual and group behaviour is a major factor of their success or failure.
The way we have behaved in the past is no longer appropriate to sustain our improvement. The operation model used by organizations in the past is no longer appropriate for continuous improvement and this is backed up by real production data.

Those who understood the problem early and pioneered appropriate change efforts are already way ahead. Many of them failed and learned and some of them only failed – if they learn to learn they still have a chance. Those who ignore the need to change may survive temporarily but soon enough new businesses, built from the ground and with new ideas will replace them.

This post is not a warning – it is just stating what I believe is now a fact. I wrote it because I felt like writing it and I understand that it might be stating the obvious for some or be too extreme for others. Everyone is welcome to challenge or comment.

Agile links is Back!

2010-10-12T12:15:00.012+01:00

After a not so good week (for which I already had a retro with myself and listed appropriate actions, etc., etc.) weekly links is now back! (perhaps to indicate a much better week?!) So here we go:

The Scrum Compliance Who except Tobias could have put it in better words? Must read for anyone interested in Scrum.

David J Andreson's Back to Basics with Kanban David re-visits the list of the minimum requirements for implementing the Kanban approach - short and worth reading.

How to Teach Lean Thinking and Acting - by Mike Rother - Author of Toyota Kata and co-author of Learning to See. I'm so gonna read this one during my first pomodoro tomorrow morning - sounds promising.

Adding Sanity to Your Agility David Hussman shares successful coaching techniques he uses to grow sustainable agility that lasts beyond the early iterations...

Agile Is More Than a Set of Methods — It’s a Leadership Mindset Can't agree more with Christopher Avery's post although I recognise that few organisations nowadays are able to do it to that level...

Start your presentation with PUNCH Some tips on how to grab your audience's attention to help your presentation go well.

Kanban for Agile Teams Whitepaper A good read (by Mike Cottmeyer) Version one need you to register in order to download it though :(

error ASPNET: Make sure that the class defined in this code file matches the 'inherits' attribute, and that it extends the correct base class

2010-10-04T21:34:00.004+01:00

So after spending an hour digging around to find possible solution to this error and finding out all sort of weird suggestions, some reasonable and some not so reasonable (e.g. to simply use a deprecated attribute?!)

I found out that this (undoubtedly) very descriptive error could be down to another reason.. in my case I needed to extend the base class from which my pages and controls inherit to keep some information that I needed.

Well the key is in pages and controls - I only had one base class and obviously controls can't inherit from a class that inherits from page and vice versa. So if none of the other suggestions have helped .. check your base classes, what they inherit from and is it suitable for your page/controls.

Weekly agile links 27th September - 1st October 2010

2010-09-27T09:46:00.011+01:00

The Rise Of The Lean Machine An eye opening presentation by Claudio Perrone. I can immediately think of at least 5 steps I'd need right now or in the near future.

Where to Begin Your Transition to Lean-Agile
Alan Shalloway & James R. Trott give us a more practical guide to making a lean/agile transition work.

Common Myths of Kanban This is in context of software.. Kanban now popular enough to have myths!

Managers New to Agile May Not Know What to Do Johanna Rothman explains some of the problems with adopting agile..

How to be happy (but not too much) Dan Jones explains how being happy means you're more open to learning,etc.etc.

Defining What Done Means Another great article by Rachel D.

Six Key Things For Managing Agile Teams Derek Neighbors lists a number of the characteristics of collaborative teams (but not all).

A Root Cause Analysis of Agile Practices Regularly link to Karl Scotland and he does not disappoint again with a summary of a recent open space session with the above topic. Also congratulations to Karl on getting the opportunity to write a book about Kanban!

Weekly agile links 20th - 24th September 2010

2010-09-20T09:50:00.017+01:00

Essence of Scrum Originally published by Tobias Mayer in 2009 and now re-worked and adapted by David Sheriff.

Estimation and Release Planning with Fruit Salad An interesting game to learn estimation and planning on Lyssa Adkins' blog.

Podcast interview with @davegray on How Games at Work Inspire Creativity Podcast on how interactivity will make your meetings and your ideas even better.

The Quest for High Performance Tom Reynolds CSM, CSP on getting there..

The Ultimatum Game and article by Cedric B. that mainly talks about traditional organizational behaviour and how to deal with it while implementing agile/scrum.

Are Job Descriptions Illegal? Here Are 9 Reasons Why They Should Be Lou Adler challengers traditional job descriptions.

THE PROBLEMS WITH ESTIMATING BUSINESS VALUE Mike Cohn on how to estimate business value - e.g. use themes/epics not small items.

Risk Innovation or Be Beaten by Those Who Do An article about innovation not just for products but for process & leadership. By Lea Strickland.

People Help Agile Adoptions An article about change, how people cope with it and how we could go about it .. by Scott Dunn.

Mood Board Shows some process innovation in the form of 'different' kanban boards as well as explains the use of the mood board.

Performance Reviews Shift Blame, Prevent Partnership On Esther Derby's blog although it looks like it is from HBR. Explains a lot of things we seem to just accept as given.

Building a Transition Backlog Another great post by Rachel Davies based on experience with agile transitions.

John Seddon Keynote Great summary of a John Seddon's key note (by Patrick Kua). Couldn't quite get which conference was that but this does not reduce it's value. Thanks Patrick.

Agile 2010 Booklist
Yves Hanoulle went through the trouble to ask attendees for the one book they would recommend - makes a great reading list.

Slides from the Deming's Red Bead Experiment by David Joyce and as presented at Agile Australia 2010.

Scrum is great! .. but what is wrong with it? (100th Post!)

2010-09-16T16:23:00.004+01:00

I was wondering how to avoid my 100th post to be a 'weekly links' post and was presented with the opportunity today.

Well this is not really the full post that the title suggests but a "Bare Talk" (as they call it) which I suggested for Scrum Gathering 2010 in Amsterdam.
If it gets into top 6 then I might get the chance to (write &) present the actual talk/article.

So the link is here: "Scrum is great! .. but what is wrong with it?" and I'll need your votes to make it happen!

Thanks for your support!

Weekly agile links 13th - 18th September 2010

2010-09-10T19:19:00.012+01:00

A Survival Guide for New Agile Coaches New Blog Series by Dave Rooney

Lean Bicycle Factory Demonstration Game This is a great Lean Game that you can play alone or with your team. I found it was really great in showing some lean principles.

STEAL THIS PRESENTATION! Some tips on making your presentation less boring. I'm would also suggest splitting your presentation parts in 10 minutes blocks and have activities in between.

Slicing and Dicing Epic User Stories Some tips from Rachel Davis on splitting big user stories.

How BA uses Agile An explanation from BA of how the Agile has helped IT projects to deliver more value, sooner.

The Joy of Craftsmanship Matt Wynne explains why for him craftsmanship is about finding joy in your work.

GAMING INCENTIVES via Esther Derby. Mainly talks about toddlers but I am pretty sure it would work exactly the same way with adults (not that I have seen it anywhere!)

Speaking is a Team Sport: 3 Ways to be Responsive to Your Audience The same message keeps coming back to me whether it is in books, articles or tweets. so time to remember and learn ;)

Social-Technical Systems The slides from Mary Poppendieck's seminar "Social-Technical Systems" at Crisp published by Henrik Kinberg. Also has a link to Dan Pink's amazing talk on motivation.

Weekly agile links 6th - 10th September 2010

2010-09-07T14:01:00.019+01:00

It seems like links are flowing from everywhere these days and more and more knowledge flies around us.. we only have to reach out and learn. I hope you will find plenty of interesting articles in my collection this week. Happy reading!

Article: Lean And Agile — Roommates, Married Or Twins? Very interesting post by Gil Broza briefly describing a panel discussion with this title at Agile 2010.

Agile is Ready for the Enterprise Michael Hugos explains how mature has agile become in the last 20 years or so.

JOB is a four-letter word Harold Jarche on the inadequacy between the way we structure jobs and the current networked reality.

Agile2010 Bag Packing with Kanban Karl Scotland presents an exciting real world kanban experiment + video.

Is “Agile Methodology” an Oxymoron and Counterintuitive to Agile-Lean Product Development and Craftsmanship? by Russel Pannone. Perhaps worth reading if I could place it higher than all of my other tasks (unlikely).

Reading The Toyota Way Matteo Vaccari with some thoughts on how this book changes his view.

BUT /MY/ TEAM NEEDS A LEADER Can teams function without a leader? Check this Esther Derby article for the answer.

An interview with Jerry Weinberg Thanks to Jon Jagger

The Thinking Tool called Agile Henrik Kniberg's slides from his keynote @ Lean/Agile/Scrum conference in Zurich - "The Thinking Tool Called Agile"

Collaboration Game: Where Are Your Keys? This got me interested in the game so I am reading a bit more about it here

Simplicity: A New Model A nice long post by Jurgen Appelo on simple and complex systems and rules.

10 Tips on Presenting at Conferences Thanks to Cory Foy

How do I know if my PEOPLE are being fully utilized? by Richard Cheng. I changed the word resource to people as this is what this article is about.

Agile Ruined My Life Some interesting agile implementation horror stories by Daniel Markham and some thoughts on the reasons why such things are common.

Success with Agile Managers Here's a great extract from a book I am currently reading. The article is by Clinton Keith and explains why we need the role of Agile Manager.

Solution Focused FAQ Got interested in the solution focused approach (thanks to Dadi) during acg-uk this year and this FAQ comes handy to help me learn more.

Weekly agile links 23rd - 27th August 2010

2010-08-20T13:42:00.022+01:00

Well, here's my second week of holiday for this year.. and a long list of links is ready to be published. Next week I am off (kind of a annual reset phase) and hopefully should be back with more links after the break.. ;)

Enjoy!

Agile release pattern: Feature-on/off-switch Nice suggestion by Johannes Brodwall - would be very useful to have it for every feature!

Motivation from the Mosaic Project Services Pty Ltd Blog. Mainly discusses Dan Pink's talk

Middleware Management pitfalls 8. Application immaturity by Sander Hautvast

Using the Class of Service Concept To Optimize Flow, Manage Risk, and Increase Predictability Nice guide to Class of service by Jeff Anderson

The Fallacy Of ReUse Udi Dahan explains why 'getting things done faster' is not aid too much by code reuse.

Seth Godin Gives Up on Traditional Book Publishing Some Lean Thinking applied by Seth Godin...

The Benefits of Making the Shift to Student-Centered Teaching Training from the back of the room applied to colleges and unis... yes, it does make sense!

5 Danger Signs of Frozen Thinking Tim Berry explains it in simple words... yeah read carefully and think again..

The One With The Fifty Percent Resources Geoff Watts on multi-tasking and treating people as resources.

Creating and Sustaining Agile Culture Janet Gregory presenting @ Skillsmatter.

Don’t Call Me a Guru, Dammit! Rick Ladd republishes a few years old article/interview with Mr. Ackoff from the telegraph - Anti-guru of joined-up management

Khan Academy deserves a link purely for the great collection of training videos it is. Thanks for sharing.

Some thoughts on Senior management by Seth Godin

The Hole in the Soul of Business Every organization is “values-driven.” The only question is, what values are in the driver’s seat? - this is an article about business and values and a must read one.

Watching “agile” move from a common-sense philosophy to an organized, detailed practice A very long and intriguing article by Edward Yourdon on the eveolution of agile.

Re-imagining Agile part 1: Why it shouldn't be done, and how to do it This one seems to be discussing the principles of Agile software development - have not read it yet though.

Weekly agile links 16th - 20th August 2010

2010-08-17T05:29:00.011+01:00

The Most Important Thing You need to read this article by Jack Uldrich. It is very important for our future.

Agile Coaches Dojo workshop presentation by Rachel Davis

A reminder: Deming's 14 points or guide to transforming into a lean company - invaluable.

On Improv, Agile, and Fear at Agile Coach Camp Canada 2010 report by Todd Charron

Four Team Self Awareness Discussion Activities This goes straight to my favourite links. Seems like a good collection of activities that can be used on many occasions.

Project Communication Plan - How to prepare for it? Could be useful in not so Agile environments or can simply serve as reminder of what useful information might be required.

3 Project Recovery Methods This has some PMI stuff in it but again could be useful at some point.

Setting the Record Straight: I Love Scrum Alan Shalloway, CEO Net Objectives about Scrum and other methods. Interesting read.

Small Changes – Small Improvements Ketil Jensen with some ideas about Kanban and the move from Scrum.

Agile Brushstrokes: The Art of Choosing an Agile Transition Style - Joshua Kerievsky on transition options.

Weekly agile links 9th - 13th August 2010

2010-08-11T08:00:00.013+01:00

Agile coaching tips: make the planning poker easier and more visual Jean Claude GROSJEAN of Valtech gives us some tips to improve planning poker estimation.

Should we adjust the time box in Scrum? Some reasoning to help explaining why the answer is no.

Kotter’s 8-Step Change Model A step by step guide to J. Kotter's change model (from his book 'leading change')

Little's Law explained and with examples. good find.

Facilitation activities A list of facilitation methods. Perhaps more than you can read in a year!

The World of Work Will Witness 10 Changes During the Next 10 Years according to Gartner “Work will become less routine, characterized by increased volatility, hyperconnectedness, 'swarming' and more”.. very agile-ish, collaborative culture-ish as well

Output-Based Agreements: assuring the customer that agile delivers Grant Rule's notes from his 5 min talk at NonAgile2010

Why Not to Focus on a Company’s Culture Alan Shalloway with some thoughts based on the book Creating A Lean Culture: Tools To Sustain Lean Conversions by David Mann

That’s the trouble with targets Glyn Lumley has not featured for some time but here he is again with some useful explanation about the issues with targets.

Becoming an Effective Coach I recently found this wiki and am posting a link to one of the first articles I've read there.

Weekly agile links 2nd - 7th August 2010

2010-08-02T11:27:00.014+01:00

Looks like being in India does not mean articles are getting fewer. Due to jet lag and food lag I am only able schedule the publishing on Sunday so hopefully (if I calculated zones correctly) it will be available at some point on Monday,

I hope you find something useful - Happy reading!

Leading from behind A short one, more like advice.. similar idea to training from the back of the room.

We’re not Japanese and we don’t build cars I couldn't help citing Konosuke Matsushita: “We are going to win and the industrial west is going to lose: there’s nothing much you can do about it, because the reasons for your failure are within yourselves. Your firms are built on the Taylor model; even worse, so are your heads. For you, the essence of management is getting the ideas out of the heads of the bosses and into the hands of labour. We are beyond the Taylor model.”. Read this article - and try to understand it.

Building Trust on Agile Teams by Rachel Davis - useful thoughts on building trust - again a mention of Patrick Lencioni's excellent book

The economics of value and localism Another article by professor John Seddon. I wish more people who make public sector decisions read & understand it.

The System Behind the behaviour I love these kind of stories .. this time it is by Ester Derby and published in Better Software

5 CMMI misconceptions in the agile community Assumptions, misconceptions.. they usually are at the bottom of every conflict.. Looks interesting though not sure how relevant is CMMI in todays world.

Stop starting and start finishing Jason Yip gives some tips on how to start doing large and complicated tasks.

Forget Brainstorming I have recently said that in front of a friend and he questioned why? I think Po Bronson and Ashley Merryman give far better answer than I did.. I just happened to have experienced great results with a modification of the traditional brainstorming. This article goes further than that- very interesting read.

Double loop learning

2010-07-23T16:19:00.007+01:00

I do apologize about the white space. I made the mistake to type this in word and use a table and then failed to figure out how to get it into blogger nicer than what you see below. Hopefully the content is in there and that is the important bit ;)

This was a session led by Benjamin Mitchell. He got me
interested in the topic because this were the first 3 words he said when he
arrived ;) There were a lot of people in this session and I was late so I do
not have the names instead I focused on trying to capture as much as I could.

The main idea as far as I understood is that there are a
couple of behaviour models when talking to people and based on which you choose
you get different value in the response. The goal is to choose a strategy/model
that allows you to generate learning (double loop learning) rather than to
close the communication loop and generate... Nothing?!

So this is how it looked like:

Governing variables

Action strategies

Consequences

Model 1

-
Win, do not lose

-
Achieve your purpose

-
Suppress emotion

-
Emphasize rationality

-
Control environment

-
Track

-
Protect self

-
defensive relationship

-
little public

-
reduces valid information

Everything above characterizes single loop
learning

We revert to this mode when we feel threatened or
embarrassed

Model 2

-
Valid info

-
Feel informed and have been
given choice

-
Internal commitment

-
Shared control

-
Illustrate evaluations

-
Surface conflict views

-
Encourage public testing

-
High freedom of choice

-
Increased likelihood of double loop learning

-
Minimum defensive relationship

Defensive routines are: easing in, requesting help,
delivering bad news, saving face. Bypass routines are covered up: inventing
motives – e.g. if I explain harder or overwhelm them with my logic they will
get it; holding others accountable; casual explanations; story telling.

It is apparently all explained by Chris Argyris’a and I have
made notes of 2 books – “59 seconds” and “Discussing the undiscussable”.

The last thing I have looks like this ( which presumably
represents a system or organization)

Thinking -> System -> Performance

We need to change the thinking to move to double loop
learning.

ACG2010 - Afternoon sessions

2010-07-23T12:00:00.002+01:00

I decided to combine the following two because I do not have a lot on them. I started the slot in the first one but ended it in the second so I hope the notes I have can be useful.

The first session was “Game-sense approach to coaching” and was initiated by Steve Tooke. Also present were Matt Wynne, Patrick Kua, Enrique, Dave Harvey and The Bus – the latter being the main reason I changed sessions because I could hardly hear what people were saying.

The idea behind this session as far as I understood it was to link the coaching approach in for example coaching a Rugby team to working the same way with software development teams. Developing people’s skills while playing a game and developing a situational awareness. We tend to do coaching as part of the game in software development but in rugby for example you coach prior to the game. So we do not get opportunities to coach – we’re expected to help the team improve while they deliver. One suggestion to introduce practices is to start with a simple games and add more rules as you go.

At this point I left unfortunately even though the topic was very interesting..
And I joined Dadi’s session on Solutions Focused (Agile) Coaching. I believe it was inspired by a book “The Solution Focus – making coaching & change simple” by Paul Jackson & Mark McKergow

What is wanted?
Vs.
What is lacking?

We’re here to help teams improve. Not sharing info for solutions you know about is negligent – e.g. If the team identifies that there is not enough testing they may decide that the solution is to introduce more test engineers while you may know that TDD/BDD approach is an alternative solution.

Once again the issue about retro items becoming sprint backlog items came up. Makes you (and the team) think how much needs/can change.

Somebody asked if there really is one approach to everything? A tool perhaps is not always applicable. But this approach can be used for the definition of Done- e.g. What will satisfy you that you’ve done a good job?

This approach is also good for solving a problem perhaps not generally making the team better.

I made a reference to a book “Discussing the Undiscussable” by William R. Noonan

Giving up as a coach

2010-07-23T11:33:00.001+01:00

Xavier wanted to have this discussion on when do you give up as a coach.
It was attended by Dadi, Liz, Marc L, Patrick Kua, Mack Adams, Racha H, Petra Skapa, Gordon Barrs, Rachel D and perhaps a few others who joined in later on.

I thought it is an interesting one because as a change agent it is inevitable to consider giving up especially when you’re introducing a considerable change and people usually resist changing and even if you find your way around getting them to define their own change it does take time and can be frustrating.

We started by discussing if giving up is a failure. Xavier posed his questions – at what point it is not worth it? What does it mean to give up?

It was pointed out that if teams or individuals don’t want to be coached then we should look for underlying problems. We could try understanding how to game agile(the change) in people’s favour.

For some teams it might be necessary to ask the question – is Agile right? Is Coaching right?

The problem could be in product strategy as well. Teams might be asked to deliver the wrong thing or with less quality which is why they could be de-motivated.
Most of the time finding the problems within the team can be crucial to understanding what is wrong elsewhere in the organization.

Xavier pointed out that as a non technical coach it might be difficult to teach technical practices in which case you only suggest but cannot really mentor.
Do you estimate impediments or organizational changes – for example introducing TDD?

The group said yes of course – they take time.
Sometimes giving up can be useful so we should always have exit criteria- if you have to leave when you do then give them the feedback. They may not understand it at that point in time but when/if their organization moves in the right direction they eventually will and they will call you back. Being honest could be good even if it means you have to leave.

Coaching people on the team to be coaches can be useful for you exit criteria - what happens when you leave?

Someone mentioned the situational leadership model- with 4 phases – telling, selling participating, delegating.

Are we able to coach executive level managers? Must be a very good coach, must be able to help them discover things.

Transformational backlog is important – you have something to start with and it shows that you do work. For reference - Leading change – Richard Durnall’s blog

Presentation is NOT facilitation

2010-07-19T14:41:00.001+01:00

This was a well attended session suggested by Tobias Mayer. The people that I remember in the session were: Manav Mehan, Petri, Petra, Dave Draper, Simon Kirk, Dave Harvey, Simon M, Paul D and Laura. Apologies to those that were there but I can’t remember.

The session was inspired by a book I am currently reading – Training from the back of the room which is one of the two reasons I decided to join this session. The other reason is that last year I learned a lot from one of Tobias’ sessions.

It began with Tobias setting the scene and explaining a little bit about what he meant by this title. Learning should be a shared experience and slides are a prescription. Slides effectively are anti-agile, they often are corrupt and wrong.

People come with knowledge so we should not stand as experts. As a trainer or presenter – leave your ego at the door. The experience should be learner centric. For example: don’t put the slides first up. Use a flipchart for the topic (flipchart could still be about me – but helps build some trust in your ability – as you do stuff – e.g. write on the flipchart not just flick slides)

Someone mentioned a useful training “Think on your feed” which resembles the same practices. We then split into groups of 4. Smaller groups mean more people are likely to contribute. We discussed “why do we have slides?” Someone say they are the equivalent of the Gantt charts. We have charts because the business sees them as the product (training) that they sell/buy.

We then talked about how we teach Scrum. People seem to teach Scrum as a process, not its values and this is why it often fails. Most people learn by doing or discovering for themselves. We don’t have to talk about values – instead demonstrate them..
Training must be seen as a holistic process. People walk out with about 10% of the training – however value changes stick.

Tobias said that he has removed his Q&A sections. How would you do that? When training from the front of the room people resist and argue with trainings and this usually goes nowhere.

People’s brain is most open at the start and at the end of the sessions. For example use 5 flipcharts with different questions. The moment someone walks in ask them to go to a flipchart, find a partner and start answering questions to each other.
Tobias also said that he printed his slides and put the around the room rather than showing a slideshow.
Don’t be afraid to say ‘I don’t know’

How to engage people at the beginnings and endings?
- Game straight away? E.g. lego pieces
- Ask people to explain to each other – they’ll remember more.
Overall it was a good discussion. I perhaps expected a little more based on my experience from the year before but still a good value and some excellent ideas.

Thanks All!

Weekly agile links 19th July - 23rd July 2010

2010-07-19T08:45:00.012+01:00

Agile: Doing the wrong thing righter Bob Marshall with his point of view on whether Agile helps or not overall. Judge for yourself ;)

Programme Level Kanban David Joyce with a different approach to scaling agile - program level kanban board to replace Scrum of scrums. They look pretty similar approaches, don't they?

Coaching Agile Teams Podcast Lyssa Adkins talks about her new book.

The Flow Experiment based on maths example. Good illustration.

Ester Derby's Coaching Toolkit 'As a coach, your job is not to solve or do—it’s to support other people as they develop skills and capabilities ' looking forward to reading this one ;)

The Core Protocols an Experience Report by Yves Hanoulle (Part 1)

An interview with Russell L. Ackoff It is a pdf and very long. My experience tells me I should find time to read it ;)

The System Behind The Behaviour by Esther Derby (Better Software) - this helped me with an approach to a problem recently. Very good.

The Limits of Agile Alan Kelly talks about common frustrations when applying agile. Very thue. Not sure about the Is it worth it section - Coming from the point of view where I was not replacing a process with Agile I can't argue with how successful other approaches can be.

Scrum is a Silver WHAT and you want to put it WHERE? By: Mike Dwyer. I like this answer - Silver mirror ;)

Re-thinking Lean Service I am pretty sure I've had this John Seddon video before but it is so good that I am including it again.

Experiences from the coaching discipline, ACGUK 2010

2010-07-13T13:48:00.004+01:00

This was the first session I attended at ACG UK 2010 and I thought it was a great way to start a day full of open space sessions. The topic was suggested by Petra because of the many analogies with coaching in other areas and there was plenty of discussion and contributions from David Draper, Xavier, Manav, Dadi, Ali, Steve Freeman, David Harvey, Doug Hudson, Ken Powel, Mike Hogan, Mack Adams, Hedi, Nadir, Steve T and others whose names I can’t remember (sorry!).

We all agreed that coaching must start with something interesting especially in the initial phases where you’re most likely in the teaching stage. I immediately noticed that we’re really very focused on coaching Agile teams because I am sure the coaching discipline does have a specific understanding of how much directing should be used. (e.g. none)

It was suggested to break down the information we want to present and build it into a larger practice slowly. It helps if the teams want to learn but we need to make sure they understand it is ok ‘not to swim’ from day one – analogy was made based on someone’s experience being coached to swim.

It is important to start with a clear goal and help them define a goal- why do they want to learn?

Don’t come in with a pre-conceded plan – find out what people want to learn first.
Dave Harvey suggested the EPIC acronym.. e.g We coach for:
- Education
- Performance
- Innovation
- Change

I thought this can perhaps be called “The lifecycle of agile coaching”? e.g. we train then we mentor then we coach?!

The coach is not necessarily better at the skill – something that came up immediately in other sessions as well and also last year. For example 90% of swimming coaches have never been professionals.

Analogy with Rugby coaching: the coach is a facilitator – the players are the experts.

A definition was made: The (agile) coach is a facilitator that created the environment for the team to excel. We would start driving, then observing and then looking for opportunities. Long term learning comes from discovering solutions not from being guided to them.

Don’t guide people to your outcome but facilitate them to the best outcome for them.
First come principles-> then values -> then manifesto – and then practices. (Evolution of learning/knowledge?)

Find positives? Things people would engage for –e.g. find tools. For example: coaching a skilled tennis player – little point to instruct him but rather focus on the positive aspects.

Sometimes however it is about expressing ideas. For example a team might resolve testing shortage by dedicating more time to testing and not by automating the tests which we might have already seen working well.

Difficult people – e.g. “mortgage driven development” is when people only come to work for the money. And that could be ok! Ask: what do you personally get from being on this team? Sometimes the goals could be – I’d like it to be less frustrating? Can always ask – how did that feel for you?

There are different goals in the organization:
- The Coach’s goals
- The Sponsor’s goals
- The team goals
- The individual goals

Our job is to align these goals. It is important to do 1:1s. You could point out that we spend 2/3 of our awake time at work – so why not put some extra effort in making it as pleasant as possible?

Weekly agile links 12th July - 17th July 2010

2010-07-12T10:28:00.018+01:00

We just ain't that good at risk Rich Maltzman argues that we're not good at managing risk with (only) our gut. I agree. He also argues that "the tools and techniques given to us by our PM books and mentors are worthwhile" - I would say in some contexts. Interesting read overall.

LeanSSC 2010 UK The link to all published presentations from this year's event @ Bletchely Park

How To Succeed With Scrum When Your Company Is Anti-Agile by Rob Diana. Good article that highlights the issues with the way we sell agile (and the way we've been taught to do it) and why it does not work. I agree the approach will have its benefits and it will be event better if we find ways to illustrate how good this is not by facts but by making people realise it themselves.. and then perhaps at some point they'll realize that there is a bigger problem to solve because it is a common experience that development adopts agile well.. the issue lies elsewhere..

Leaving a Legacy, How Do You Leave an Environment in Which a Team Can Continue to Grow Dan Rough's notes from the open space session with this title at Agile Coaches Gathering in UK 2010.

Kanban - how software people get it wrong Thad Scheer pointing out the mis-understanding and mis-use of Kanban. Pretty good and explains well why most companies would move a team to Kanban only after they've mastered Scrum/XP for the benefits of JIT delivery.

The Essence of Agile Henrik Kinberg's slides from his keynote "The Essence of Agile" at Agile Spain 2010, Madrid.

Millennials and Scrum, made for each another What Lyssa Adkins talks about here is exactly the place I'd choose to be. Just look at that: “Well, that’s just stupid. Who would ever choose to work that way in the world we live in?” When was the last time you heard someone who is not an agile proponent to say something like this about waterfall?!

Paul Dyson's On Estimation article says the things pretty much the way I think about them. Easy to say do not estimate, not so easy to avoid it - yes I do want to know how much it costs before I make a decision to buy it.

The Secret Sauce Recipe to Agile Coaching I am going to read ROB MYERS in detail and compare with my notes from ACGUK 2010.. the topic is hot hot hot for me right now.

Metrics Used In Testing Lots of suggestions.. pick & mix.. but remember Demming's quote: "The most important things cannot be measured."

5 Tips to Build a Real Project Dream Team Ty Kiisel on my favourite topic - building dream teams.Simple & effective.

Weekly agile links 5th July - 9th July 2010

2010-07-06T17:11:00.014+01:00

It is Agile Coaches Gathering week and I am heading to Milton Keynes early on Friday so this post will either be lucky to be published earlier or will wait until Sunday.
Looking forward to a great event and for those who cannot attend follow the twitter updates - tag #acg.

Enjoy this week's links ;)

Steps In Performing a Project Risk Audit One topic that is hot at the minute, at least according my impression..

New Maxim: If You Can’t Change the People . . . Change the System! From Tripp Babbitt's Blog

The History and Simplicity of Lean Process Improvement Brian Hunt explains a lot of the reasons behind lean and why things are the way they are.

How to Project Manage Just About Anything My busy week means I can't read this one now but the title sounds intriguing enough so I am including it.

The globally connected project team This might as well have been titled practicla advice on how to work in a distributed team. Looks good.

How Agile Projects Measure Up, and What This Means to You Executive report by Michael Mah, Senior Consultant of Cutter Consortium.

How To Tell Your PM His Leadership Skills Are Terrible? Send him to a IMPROV course? No, seriously I suck and I am proud of it!

Test Driven development with MVC and MSpec 52 minutes video, must watch for me ;)

HICSS 2011 Agile Papers - Need Reviewers! Jeff Sutherland posted this call for reviewer recently.. I wanted to do it but then considered my schedule and gave up.. any takers?

THE LEAN PRODUCT BACKLOG – ELIMINATE WASTE Roman Pichler usually has very useful things to say so worth readin..

LOOKING FOR A NEW SCRUM MASTER I am not looking for a ScrumMaster. this is just the title of the article by Thomas Karsten. Once I had to make similar choice and who knows when it might happen again?

Weekly agile links 28th June - 2nd July 2010

2010-06-28T11:58:00.018+01:00

Adventures in Accelerated Learning If you're in the business of spreading knowledge in one way or another, if you're a change agent, trainer or coach or you simply want to learn an effective way to tell a tell then you should read this article. I also highly recommend the 2 books mentioned.

Guidelines for Group Collaboration and Emergence Trust, Respect, Participation, Comittment.. A brilliant article by Venessa Miemis.. for me it created a lot broader understanding of something I've already read about elsewhere. Thanks.

12 Things the Best Bosses Believe I believe in certain things about being a great leader so this one naturally caught my attention. I find this to be a Great list with very useful reminders.

Identifying Waste Lean Thinker says “Make less, buy less, use less, throw away less.”. Sounds reasonable to me :)

Kate Oneal: Productivity 2 years old and still very relevant. From XProgramming.

Cultivate Informal Leadership Jurgen Appelo's article gives some practical advice about leadership that is worth having.

Understand Technical Debt by Playing a Game - Packing Peanuts This game sounds great fun and looks like it will demonstrate technical debt. Thanks for sharing Masa!

Risk Management Methodology Ray W. Frohnhoefer provides some useful guidance that can be used to do risk management in agile (I know, I know "agile is risk management" yet I am regularly asked how do you do it?)

A MANAGER’S GUIDE TO GETTING FEEDBACK A new article by Esther Derby. Incidentally I participated in a similar discussion on one of the agile user group boards.

How can we encourage active participation in groups after the original excitement of forming has died down? an article on Collective Self by lori which suggests that self-organizing work groups don’t live on indefinitely. I'd agree with that. Useful ideas about what options are available once you're in this situation.

Making TDD Stick: Problems and Solutions for AdoptersMark Levison's article about TDD is not about 18 months old. Still plenty of relevant ideas, some not always practical. I'd add BDD at the top of the list.

The Estimate Goat The only bad thing about this site is that I have not discovered it earlier. Great tool to give you estimates!

Your Project Needs Business Rules, Not Meetings To be honest I cannot be bothered to read this one right now and hence I will not comment on it. I am including the link as I might need it later and it does sound controversial which usually means there might be some good ideas in it.

SQL Server: Searching data in all tables in multiple databases

2010-06-21T16:14:00.008+01:00

Recently, I had to deal with a weird issue which was related to possible invalid references stored in a database. I did not know much about this database so in order to remove these instances I wanted to search through all the tables in all the databases for a specific fairly long and definitely unique string value.

Then I came across this article which suggests a great solution for searching within a single database, however I had a fair amount of databases to look through so instead I wanted to see if with a little bit of tweaking I could make it work for multiple databases. It turned out I can and I thought I'd share the result.

So below is a stored procedure that you need somewhere on the server (db not important) that will search through all the tables in each of the databases you supply as a comma delimited string. You could also rework this to be a simple script rather than a stored procedure if that suits you better.

I hope it does come useful ;)

 /****** Object: StoredProcedure [dbo].[SearchAllTables]  Script Date: 06/18/2010 11:17:56 ******/  
 IF EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[SearchAllTablesMultipleDbs]') AND type in (N'P', N'PC'))  
 DROP PROCEDURE [dbo].[SearchAllTablesMultipleDbs]  
 GO  
 CREATE PROC SearchAllTablesMultipleDbs  
 (  
      @SearchStr nvarchar(100),  
      @DBListCSV nvarchar(1000)  
 )  
 AS  
 BEGIN  
      -- Copyright © 2010 Plamen Balkanski. All rights reserved.  
      -- Uses SearchAllTables procedure written by Narayana as a basis for searching data in multiple dbs & tables .  
      -- Copyright © 2002 Narayana Vyas Kondreddi. All rights reserved.  
      -- This procedure uses the modified SearchAllTables to allow searching through a list of DBs  
      -- Note: there is almost no validation so if you use it then ensure you pass existing DB names otherwise it will fail.  
      SET NOCOUNT ON  
   DECLARE @idx int      
   DECLARE @slice nvarchar(1000)      
   DECLARE @ResultsTable varchar(100)  
   DECLARE @SqlExec nvarchar(2000)  
   DECLARE @Delimiter char(1)  
   -- You can parameterise this one if you want.  
   SET @Delimiter = ','  
   SET @ResultsTable = '##MultipleDBSearchResultsTable'  
      -- drop/recreate the global temp table - note: must be global as otherwise it is not available in the EXECs  
      EXEC( 'IF (OBJECT_ID(''tempdb..' + @ResultsTable +''') IS NOT NULL) DROP TABLE ['+ @ResultsTable + ']')  
      EXEC ('CREATE TABLE ' + @ResultsTable + ' (DbName nvarchar(370),ColumnName nvarchar(370), ColumnValue nvarchar(3630))')  
    -- Split the database names and Run SearchAllTables for each  
   SELECT @idx = 1      
   IF len(@DBListCSV)>1 AND @DBListCSV is NOT null       
   BEGIN   
           WHILE @idx!= 0      
           BEGIN      
                SET @idx = charindex(@Delimiter,@DBListCSV)      
                IF @idx!=0      
                     SET @slice = left(@DBListCSV,@idx - 1)      
                ELSE      
                     SET @slice = @DBListCSV      
                IF(len(@slice)>0)   
                BEGIN  
                     SELECT @SqlExec =  
                     ' USE ' + @slice +   
                     '  
                     DECLARE @SearchStr nvarchar(256)  
                     SET @SearchStr = ''' + @SearchStr + '''  
                     DECLARE @TableName nvarchar(256)  
                     DECLARE @SearchStr2 nvarchar(110)  
                     DECLARE   
                          @ColumnName nvarchar(128),   
                          @DbName nvarchar(256),  
                          @SqlExec2 nvarchar(1000)  
                     SET @TableName = ''''  
                     SET @SearchStr2 =''%'' + @SearchStr + ''%''  
                     WHILE @TableName IS NOT NULL  
                     BEGIN  
                               SET @ColumnName = ''''  
                               -- In here make sure we reference each database  
                               SELECT DISTINCT @TableName = MIN(QUOTENAME(TABLE_SCHEMA) + ''.'' + QUOTENAME(TABLE_NAME)),  
                                         @DbName = MIN(QUOTENAME(TABLE_CATALOG))  
                               FROM      ' + @slice +'.INFORMATION_SCHEMA.TABLES  
                               WHERE      TABLE_TYPE = ''BASE TABLE''  
                                    AND     QUOTENAME(TABLE_SCHEMA) + ''.'' + QUOTENAME(TABLE_NAME) > @TableName  
                                    AND     OBJECTPROPERTY(  
                                              OBJECT_ID(  
                                                   QUOTENAME(TABLE_SCHEMA) + ''.'' + QUOTENAME(TABLE_NAME)  
                                                    ), ''IsMSShipped''  
                                                     ) = 0  
                               WHILE (@TableName IS NOT NULL) AND (@ColumnName IS NOT NULL)  
                               BEGIN  
                                    SET @ColumnName =  
                                    (  
                                         SELECT MIN(QUOTENAME(COLUMN_NAME))  
                                         FROM      ' + @slice +'.INFORMATION_SCHEMA.COLUMNS  
                                         WHERE           TABLE_SCHEMA     = PARSENAME(@TableName, 2)  
                                              AND     TABLE_NAME     = PARSENAME(@TableName, 1)  
                                              AND     DATA_TYPE IN (''char'', ''varchar'', ''nchar'', ''nvarchar'')  
                                              AND     QUOTENAME(COLUMN_NAME) > @ColumnName  
                                    )  
                                    IF @ColumnName IS NOT NULL  
                                    BEGIN  
                                         SELECT @SqlExec2 =  
                                              ''INSERT INTO ' + @ResultsTable + ' SELECT '''''' + @DbName + '''''','''''' + @TableName + ''.'' + @ColumnName + '''''', LEFT('' + @ColumnName + '', 3630)   
                                              FROM '' + @TableName + '' (NOLOCK) ' +  
                                              ' WHERE '' + @ColumnName + '' LIKE '''''' + @SearchStr2 + ''''''''  
                                         EXEC(@SqlExec2)  
                                    END  
                               END       
                          END'  
                          EXEC(@SqlExec)  
                     END  
                SET @DBListCSV = right(@DBListCSV,len(@DBListCSV) - @idx)      
                IF len(@DBListCSV) = 0 BREAK      
           END    
      END  
      -- show results  
      EXEC (' SELECT DISTINCT DbName, ColumnName, ColumnValue FROM ' + @ResultsTable)  
 END  
 /*  
 EXEC SearchAllTablesMultipleDbs 'SearchString', 'DbName1,DbName2'  
 GO   
 */

Weekly agile links 21st - 25th April 2010

2010-06-21T10:56:00.006+01:00

Last was a very sad week for me.. :( I was devastated and pretty much off the whole week so just a few links listed.. will see if I can start adding more stuff this week.

Project Failure Modes Root causes of project failure and plenty of other interesting posts on the herding cats blog

Check this out - What a transparency in reporting an issue - lovely:)

WHY PRODUCT OWNERS SHOULD CARE ABOUT QUALITY Roman Pichler has reworked his article that already featured in Weekly Agile Links before.

Kanban case study Financial Services Kanban case study by John Dunion

Weekly Agile Links 14th-18th June

2010-06-16T16:07:00.012+01:00

Some more links from the past week. things continue to be extra busy with plenty going on and finding it difficult to spend time reading.. too bad :(

Lean-agile dogs: Are we chasing the right car? One more Scrum/Kanban article by Pascal Pinck.. some interesting thoughts on what is important.

Business Intelligence Requires Thinking . . . Not Technology Tripp Babbitt talks about business intelligence and maturity levels.

How to read a book in an hour I'm sure it is possible, just haven't quite yet mastered the tricks Jamie Flinchbaugh shares with us...

The Dolt's Guide To Self-Organization Interesting presentation on self organization by Jurgen Apello.

Kanban and Scrum – Intention and Implementation Karl Scotland finally gives the explanation why Scrum and Kanban are like apples and oranges!

AGILE PRINCIPLES REVISITED This is results from a survey asking respondents to rate how important is each of the original agile manifesto principles along with other stuff like what is essential to be considered agile. Interesting idea but they all are .. no really, they are.. Also no mention that being agile based on these results may simply mean nothing.

Animating a Blockbuster: How Pixar Built Toy Story 3 A very Scrum/Agile like process although does not mention the words.. according to e very reliable source who has actually read it ;)

Weekly Agile Links 7-11th June 2010

2010-06-08T21:53:00.008+01:00

Have I said busy in the last weeks? I obviously did not understand the meaning of the word! Anyway, I will still be collecting links and posting them here for the same reasons I started these posts and if it happens that someone finds these useful then even better. Here's my modest collection from last week. Enjoy ;)

Using an Agile Software Process with Offshore Development Martin Fowler writes about his experience with off-shore development in Bangalore. Always interesting to read what he has to say..

A Fundamental Turn Toward Concurrency in Software See, this article is 5 years old and I feel I should have read it a while back.. it is worth a bit of time ;)

June 8, 1637: Descartes Codifies Scientific Method very interesting read by Lisa Grossman

Maximum Viable Product Bradford Cross on product management, looking at some successful products & companies, looks a good read.

Belts and Tools Not Needed to Improve Service Article by Tripp Babbitt related to Systems Thinking Concepts. Generally I like the system thinking ideas.

Weekly agile links 31st May - 4th June 2010

2010-06-01T09:13:00.015+01:00

Another busy week of very little time for links.. hopefully a few good ones below..
just one more week of madness and should be able to provide better quality comments ;)

Enjoy ..

Discovering the DNA of Apple’s Innovation Engine Very interesting research about the relative values of investment in R&D, advertisement, profit per employee and how successful a company is.

New People On Your Project Mark Levison explains why adding more people to a project is a way of slowing your project down

Right.. here's another manifesto suggestion Next step of the Agile Manifesto? What is it? the Manifestos year? Otherwise this one has sensible suggestions.. I agree.

What Motivates People? No huge secrets revealed in this one. PAWEL BRODZINSKI states a truth everyone would sooner or later establish. Once you step on that road of course.. might be better staying off it longer term tbh.

Jeff Bezos and Root Cause Analysis Real 5 whys example (apparently).

SHIFTING THE PATTERN: A SYSTEMS APPROACH TO CHANGE The title kind of explains it.. Esther Derby talks about change and systems thinking..

The "Command and Control" Military Gets Agile Interesting article by Dan Mezick about what happens when the usually inflexible military 'gets' agile

Strategies for Scaling Agile Software Development Scott Ambler explains why Lean thinking is important when looking to scale agile. Perhaps also proves that agile is local optimization?!

Lean Quote of the Day Tim McMahon' lean quote is by John Kotter who reminds us that the root of success involves a sense of urgency

Weekly agile links 24th - 28th April 2010

2010-05-24T15:03:00.014+01:00

Just a few links this time.. nothing to do with the annual.. "things" I have to do every year around this time.. Been on the BDD topic this week with a visit to NxtGen in Southampton and also been doing some research so I thought I'd start with a bdd link and if that doesn't do it or you're anyway a .net folk check this as well.

All of my links from last week below. Enjoy;)

Transparency – Crucial to Engagement Surprise, surprise.. Good read though ;)

What's Agile? Individuals and Interactions or Processes and Tools? Nice reminder by Jared Richardson - Thanks! I think we should employ the practice to spend 10 minutes a day re-reading the manifesto and discussing in depth one of the points.

TDD at the System Scale Adam Whittingham on Nat Pryce and Steve Freeman's TDD session at Spa2010

On the relationship between projects and organisations And article by Kailash Awati on how projects are not isolated.

Maverick By Ricardo Semler Heard good things about this book and this is the highlighted summary. I found it by googling so hopefully it is legal.

Goals Gone WildThe Systematic Side Effects of Over-Prescribing Goal Setting (Lisa D. Ordóñez, Maurice E. Schweitzer, Adam D. Galinsky, and Max H. Bazerman) This is a 28 page explanation why performance reviews should be avoided.

Truly Agile CMMI A post by Hillel showing an example (with a video) of a team that is Agile and conforms to CMMI level 2

Weekly agile links 17th - 21st May 2010

2010-05-18T22:08:00.015+01:00

I had several busy periods during this week so I am sure I have missed on a number of great links. The ones I have below I am sure are still worth checking ;) My link of the week this time is The Bigger Picture and The Four Mindsets and three transition zones of Rightshifting - Bob Marshall finally publishes this chart which grabbed my attention when I first saw him draw it on a whiteboard.

Enjoy also the rest of my links.;)

The Rise And Fall Of Waterfall The true history of software development methodology called Waterfall... In memory of Winston Royce

Agile antipattern: Target fixation Agile Bob explains the anti pattern of fixing the target and not seeing anything else.

Why Lean is a Wicked Disease John Seddon on re-thinking industrialised processes (Enjoyed reading it)

Single-Piece Flow in Kanban Video - talk by Arlo Belshee and James Shore.

Kevin Rutherford's session on Flow Slides & links. The session is from agilenorth 2010

RETURN ON HUMAN INVESTMENT Raising our View of People and Their Possibilities By Jim Lucas

The Ten Most Common Failures of Bad Leaders Paul Sloane brings us the result of a large survey highlighting the most common failure of leaders.

Getting RE-TRAINED to be a ScrumMaster My friend Geoff Watts has published another great article to help Scrum masters understanding their role.

WHEN SCRUM IS NOT A GOOD FIT Here's another article by the CST who certified me several years ago. Roman suggests using Kanban when Scrum is not a good fit.

The Three Manifestos Nice pictures of the 3 most important manifestos of our time ;)

Weekly agile links 10th - 15th May 2010

2010-05-11T13:37:00.017+01:00

A week of trying to go back to normal and a week of new opportunities and some exciting changes. At the end of last week Leeds United (the team I support) won promotion to the Championship and while that has nothing to do with Agile links it does represent a positive development for me;) Anyway on the links topic my link of the week is here:
The Problem with the World? "Dear Sirs,I am.Sincerely yours,G.K. Chesterton"

And the rest of my links:

Can I Do Perfect Scrum and Still Fail? Yes. Read more if you want to find out Mike Cottmeyer's somewhat longer answer.

One Team: Replay initially published in July of 2001 by Kent Beck. Classic read.

Dee Hock’s four priorities for managers How obvious isn't it? And how well misunderstood .. manage what?

Scrum or Kanban? YES! You have seen these questions I am sure.. which one is best, when to use each, and so on.. Every process has a sweet spot says Michael Sahota and concludes - We need to know both Scrum/XP and Kanban

Agile and Lean Product Development – Yesteryear, Today and into the Future Rally dev post including opinions of their own gurus Ryan Martens and Jean Tabaka.

Scrum to Kanban transition Case study published by Mattias Skarin

Word to the Wise Someone finally has defined wisdom.. apparently

Approaches to Organizational Change a post by Michael Sahota which is mainly about Mary Poppendieck talk “What’s wrong with targets?” whose goal is to 'trash Management by Objectives'

The Missing Link To Lean Six Sigma - Emotional Intelligence ANKIT PATEL explains why lean and six sigma should be viewed as more than just tools.

Career paths for technical folks Bob Marshall on the always interesting topic of career paths and why developers should not move into management if they do not want to..

Weekly agile links 26th April - 7th May 2010

2010-04-26T13:28:00.014+01:00

Here's an extended week due to me going on a training for several days and then picking up the pieces in all the areas I am engaged with... Due to being busy I have not read most of these so would be difficult to recommend any.. What I can recommend is the Agile Coaches Gathering UK in Milton Keynes in July. All details are here

So my link over the last few weeks.. I am sure there's plenty of interesting stuff that I need to catch up ..

It’s All The Same – Leadership Challenges and Organizational Dynamics by Mark Graban

What is Kanban? Agile Denver meet on Kanban lean software development methodology, presented by Frank Vega and Brad Swanson.

Saving your job or speaking the truth No comment really.. I need to keep saving my job..

Simon Sinek: How great leaders inspire action Sounds intriguing and on my favourite subject- leadership

Real Developers Don't Need Unit Tests Interesting point of view in the era of TDD, BDD, EDD and ?DD..

Why You Shouldn’t Hire the Best and the Brightest Candidate By Michelle Malay Carter

The Role of the Agile Coach Allan Kelly summarizes it for the benefit of everyone who needs the extra explanation.

How One Leads Others: The Tone at the TopBy Dr. Jeffrey Magee, PDM, CSP, CMC.. this is part 7 so perhaps best to start from the beginning (only if it was easy to find it)

WHAT THE BIBLE SAYS ABOUT LEADERSHIP AND DELEGATION and TWO POSTURES TOWARD CHANGE Two interesting posts by Michael Hyatt on leadership and change

2 ideal cases for continuous flow another post about why choose Kanban over Scrum .. got the mesage

Building an Agile Environment this looks very interesting to me, especially we as a team have had the chance to change our environment to suit us..

How to give a talk One to check later. could be useful. these days it is very likely that at some point you will be required to give a talk..

Weekly agile links 19th - 23rd April 2010

2010-04-23T12:12:00.003+01:00

Another glorious week of link collecting and reading and learning. Wonderful stuff follows, so be prepared ;) My link of the week is a true an revealing story - The story BCG offered me $16,000 not to tell

I also have a Quote of the week this time and it is about a hot topic in the recent weeks - effectiveness or efficiency? - "You're efficient when you do something with minimum waste. And you're effective when you're doing the right thing" ~ Slack

All of my links below:

Good collection of Rachel Davis' Tips on organizing an Agile Open Space I've actually seen Rachel in action and would highly recommend her tips - Rachel and Mike Sutton did a brilliant job at Agile Coaches Gathering last year.

It is that time of the year again and here're two posts on retaining people and performance evaluations. Retaining Employees through Respect and Development by Mark Graban and Want to improve performance? Cancel reviews By Erin Conroy

A Kanban Multiverse – not from LeanSSC Atlanta Karl Scotland's presentation that he was going to do at LeanSSC but couldn't due to the Volcano air travel disruption.

Learning the Basics of Agile Alan Dayley has created a nice introduction - will recommend to newbies from now on.

A couple of posts on Scrum Masters and what could go wrong with Daily scrums- quite enjoyed them as they serve as good reminders..
Paul Goddard's Top 5 ScrumMaster Bloopers
and Mark Levison's Pathologies of the Daily Standup

Doing the wrong things righter?
An article in System Thinking Review on Lean

The story BCG offered me $16,000 not to tell - A stunning true story revealing a very much non-unique corporate culture and what it does to people

Why I withdrew from SEMAT After publishing a link to SEMAT's overview last week, here's now Alistair Cockburn's reasons not to participate.

Using Product Portfolio Management to Improve the Efficiency of Teams ALAN SHALLOWAY explains why you should not start an agile transition ignoring the portfolio of products.

Kanban Systems While this article by James Shore is 2 years old I really like the way it presents Kanban - I finally feel like I understand it!

Yes, Everyone Really Does Hate Performance Reviews by Samuel A. Culbert ... one for me to read..

Scrum doesnʼt work in China! ? Bas Vodde's presentation on cultural differences and Scrum. Liked it.

The Art of Agile Development: Estimating Another piece from James Shore's book. Looks very useful for explaining the problems with traditional estimation.

Interview with a friend...

2010-04-22T17:40:00.001+01:00

This week I have been in touch with an old friend who also is an experienced software development guy (and whose name I cannot mention) and who’s been around for some time and has been working in agile environments for the last several years. Not much of a blogger himself I approached him for a short interview as I thought that after seeing plenty of organizations and approaches he must be in a good position to share his experience. He agreed to do so and I am publishing it now even though it has to be anonymously. I have asked a few questions and I have the permission to provide the answers which I have edited where appropriate without changing any of the meaning. Here’s the short interview.

So based on your experience does Scrum work?
- I’ve seen it work and yes it does work in the right context

And does Agile work?
- Not sure if I see them as very different things so yes, I’ve seen Agile work as well and I believe it does work in most contexts.

Why wouldn’t Agile or Scrum work?

- The most common mistake I’ve seen is that whatever method or framework is applied it is not suitable to resolve the specific business problem. There could be plenty of other reasons related to the way change is applied and how well people adapt to the change of approach.

What could impede Agile?

- Political behaviour takes top place for me. People having their own agenda, hiding information for that reason and insisting on their own “I” instead of the bigger “we”.

What can we do to help Agile adoption?

- The first step to me is to understand what a collaborative culture is and start applying its principles. This will help your organization regardless of what you do next. If you find that you have to deal with people that cannot adapt on a daily basis then see if you can move them somewhere else and carry on without them. If you can’t then don’t waste your time. This is not easy to do so if you do not win support from the highest instance you may as well not bother.

And finally what is the essence of Agile and why so many methods – XP, Scrum, Kanban...

- Agile (as in not the word – the actual Agile Development) is the Agile manifesto – it is time insensitive. Read it; if you do not understand it then go do something else. Various methods work in various environments. If there is a pattern big enough then it may result in a different method created and sustained by the community. Agile will always be changing, Agile is the set of best practices for being efficient process wise. Not applying best practises that you know about is sub-optimal. Applying them without considering what’s right for your context can be disastrous.

Weekly agile links 12th - 16th April 2010

2010-04-13T17:04:00.009+01:00

Interesting (if not thrilling) week for me filled with both positive and not so positive emotions. We had Bob Marshall @ Agile South Coast at the start of the week and last night I attended NxtGen Southampton for Visual Studio 2010 launch presentation by Jason Z who happens to be GM of the Visual Studio team. As a result I have not been very active and missed most of the links flying around. Yet I hope I have a nice and quality collection below.

My link of the week is The Psychology of Lean Management By Michael Ballé

I hope you find something useful to read ;)

Agility, Measurement,and Motivation A free article by Jim Highsmith, Director of Cutter Consortium

Agile Transformations fail because of FEAR... "Have you heard this before?" asks Michael Depaoli and challenges the statement used by too many..

Agile and Management of Change If you go into the trouble of reading this post by Elderclei Regis Reami you're likely to think - yeah nicely said but unlikely to happen. I am sure it can happen though and one day I am going to write a report based on actual experience!

Stumbling Through Mediocrity I am yet to read it.. which is why it might miss on link of the week.. it seems very interesting so .. top of my to read list..

WHY PRODUCT OWNERS SHOULD CARE ABOUT QUALITY Roman Pichler with another good (and short) article to help shape the PO role.

The product owner and the product-shaped hole What the product owner needs to worry about according to Jeff Patton. One for me to read later on.

Agile Record A new magazine. Looks promising.

[link of the week]
The Psychology of Lean Management By Michael Ballé, author of The Lean Manager. Kind of long but a must read really.. if I managed to survive it I am sure you'll do too;)

SEMAT - Software Engineering Method and Theory by Mark Levison.. another manifesto.. similar to the software craftsmanship idea

Weekly agile links 6th - 9 April 2010

2010-04-06T09:04:00.016+01:00

Here we go again, I actually had a day off on Friday and a nice long holiday so finally getting time to publish last week's links. I hope you find something useful ;)

8 Tips for Performance Metrics Jurgen Appelo again with some extracts from his book. Re-confirms my thoughts on performance measurement.

The Agile Manifesto… and status report John Mortimer re-reads the agile manifesto every year so here's his 2010 verdict

The Failure of Failure An HBR article by Michael Schrage on the different types of failure

A Simple CST Application Process On 6th April the Scrum Alliance Board of Directors approved a new CST application process and this is the link to it.

Pluralcast #12 : The Future of Scrum with Ken Schwaber Interesting comments on what happened between Ken and the SA and an unfortunate word used to describe Scrum ;)

Top 150 Management & Leadership Blogs Another entry by Jurgen Appelo - this time he used his own algorithm to create a top of leadership blogs. Good idea - I know what to read now.

Achieving Fast, Flexible Flow Brian Lawley on product management and how to make it leaner.

The Case for Sprint Preview Meetings We call them pre-planning, requirements workshops or something else - Charles Bradley comes up with a new name.

Listening is a Top Leadership Skill Hugh Ballou explains why listening is so important. I like this transformational stuff ;)

Better Software March/April 2010 This issue has several interesting articles including one by Mike Cohn, some interesting exploratory testing stuff and one on collaboration.

THE INFLUENCE OF ORGANIZATIONAL STRUCTURE ON SOFTWARE QUALITY: AN EMPIRICAL CASE STUDY A pdf containing a study by MS people apparently. A bit too long for me with the time I currently have but worth reading later on so here's a good place for me to store the link.

Agile South Coast: The Next Group Meeting will be on 12th April

2010-03-29T21:42:00.001+01:00

In April at the Agile South Coast monthly event we're having Bob
Marshall (twitter.com/flowchainsensei) for an exciting and revealing
discussion about coaching skills.

Coaching is becoming an extremely important part of today's job and an integral part of all Agile transformations.

Bob is a highly experienced transformational leader, currently chief coach at Falling
Blossoms whose main goal is increasing effectiveness for UK technology businesses through transformational leadership.

Come along to learn some new skills and have a great conversation with true agilists and while on it bring any questions you might want Bob or the rest if us to answer.

We'll also have some free training to give away for those most active in the discussion.

Weekly agile links 29 March - 2 April 2010

2010-03-29T16:17:00.012+01:00

Short and busy week produced less links than before. At least this time I won't forget to post it.
My Link of the week is Mike Cottmeyer's advice on how to build a large organization.

Enjoy reading ;)

[link of the week]
How to Build a Large Agile Organization Mike Cottmeyer suggests a way of large scale Agile that I can actually see!

Management Mistakes (Part 1) Michael Bolton's rather amusing story which brilliantly pictures so many of my past managers ;)

Optimize the Whole = Measure at All Levels Jurgen Appelo once again with a valuable article on what to measure and why.

Systems Thinking and The “Flop” by Tripp Babbitt. Something for me to remind me to read it really rather than recommending it. (which doesn't mean it is not good).

Managers: Reduce Stress by Increasing the Feedback by Steve Roesler.Reminds me of the famous quote that truth always is uncovered in the end so why not get there fast.

Ten Answers from a non-manager Markus Gärtner provides the answers to Jurgen Appelo's questions from last week. Blog-dialog ;)

Appraisals aren't about the work anymore by ROB WORTH. Yet another one for me to remind me to read it. Kind of busy week ;)

6 Months of Reflection Leadership Tom Glover reflects on what he learned from publishing in his blog in the last 6 months. Haven't read it in full.

Unwritten Rules of Communication Mike Myatt on leadership and effective communication. Sounds interesting so I should be reading it soon;).

Scrum, Kanban, Waterfall? Whatever you call your process, it’s broken I struggled to find out who the author is - it sounds challenging and interesting though.

Weekly agile links 22-26 Mar 2010

2010-03-19T15:46:00.022Z

Reasons An incredibly good article by Gerald M. Weinberg. Contains a nice tool to deal with situation change agents have to deal with now and then. A must read really!

Team Estimation Game - This is a 2 years old post by Shane Duan which describes a game by Steve Bockman. I came across the link and I thought I'd publish it as I've seen the game before (last year's ScrumFest in Brighton) and I liked it ;)

Stop. Reflect. Adapt. Matthias Marschall on The 3 Steps to Stop Writing Bad Code

Self-Facilitation Skills for Teams Esther Derby on looks into self-organizing teams and beyond technical work.

Experiment Driven Development - The Post-Agile Way Here comes another ?DD - this time it is the EDD. Nonetheless it does sound interesting and 'the business' can learn a lot from it.

7 Productivity Tips From Ernest Hemingway And today still valid as ever (thanks to WBRIGGS)

Leadership Development: Just in Case or Just in Time Tom Glover with another interesting post on leadership. I like how Tom specifies the reading time ;)

Goal-driven Development Eli Lopian presents some valid thoughts on the wrongs of performance management as we know it and gives examples of why setting a goal is important.

The Dolt's Guide To Self-Organization Jurgen Appelo's super simple explanation of self organization. Reading time 10-15 minutes ;)

Facilitating A Kanban Konversation One of the great Kanban leaders Karl Scotland talks about facilitation in Kanban environment - e.g. goldfish bowl or just fishbowl as some call it.

A Managers Role in Hiring Esther Derby continues her management series with a suggestion about how to do hiring in collaborative environment.

Doing It Wrong An amazing podcast of one of the last interviews Russell Ackoff gave. Insightful and revealing. Evry C*O must be made to listen to it and understand it.

Agile coaching skills course John McFadyen's take from Rachel Davis's recent course @ skillsmatter

Technical Excellence isn’t enough Eric Brown on technical excellence, point 0 and what else is do you need (I need to read it really ;))

10 Questions to Ask Your New Manager Jurgen Appelo again - this time with 10 questions you should know to ask when interviewed.

Weekly Agile Links 15-19 Mar 2010

2010-03-10T16:03:00.036Z

My quote of the week this time comes from a 33 years old article by Melvin Conway - yes you've guessed it - it's the famous Conway law - "Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization's communication structure"

Otherwise another huge week on links so I guess I have to up my selection criteria so I can post a manageable number of links and only those of best quality ;)

My Link of the week this time is Toyota’s journey from Waterfall to Lean software development courtesy of Henrik Kniberg who brings us an interesting story.

All the links below - I hope you enjoy reading/watching ;)

What Great Bosses Know about Teams vs. Silos Do you have a team or a silo? Great article & podcast discussing leadership & team dysfunctions

Scrum Gathering Musings Another blog post with impressions from the SG2010 in Orlando, this time by Karl Scotland.

Shifting the Burden of Establishing Priorities An interesting exercise by Esther Derby demonstrating that "without prioritization nothing is priority"

Brian Marick on 4 Challenges and 5 Guiding Values of Agile Software Development looks interesting - must find time to watch it!

Toyota’s journey from Waterfall to Lean software development Guess what? Toyota software development currently is running waterfall. Henrik Kniberg's been there and is happy to share his experience.

Orlando Scrum Gathering overview by Bob Hartman -very useful if you want an informative yet not so long summary.

Agile Coaching CirclesNotes from a SG2010 open space session on how to avoid feeling isolated and unsupported as a coach

An agenda is the killer of productivity in meetings Hugh Ballou has something to say about activities and outcomes - usually worth reading when he writes.

Team Roles Tom Glover writes something very similar to the DISC model with very similar claims that all of these roles are necessary as well.

Migrating from Scrum to Scrumban - an Experience Report from a Kanban Virgin Chris Pitts presents his experience of moving from Scrum to Scrum ban (which is a combination of Scrum & Kanban)

The new issue of Better Software with some great articles from Mike Cohn, Lee Copeland, Jon Kohl and others

Harrison Owen: Use Open Space for amazing results Michael Sahota's notes on Harrison Owen's keynote speech at Scrum Gathering 2010 in Orlando

Fix the Small Problems First After winning my article of the week last time here is another article by Jurgen Appelo. This time on fixing small cracks. Has in it my favourite example about the NY police and crime rates.

Managers Are Clueless Pawel Brodzinski states the obvious. I wish more managers could admit it!

What happened to the Deming philosophy?A great article about W. Edwards Deming (by Rip Stauffer)

Large-Scale Agile Another scaling agile article by James Shore

An Open Space endorsement of Scrum Tobias posted this reproduction of the email sent to Scrum Alliance by Suzanne Daigle who worked with Harrison Owen on the Open Space session at the American SG2010. A great feedback for SA.

Are We Agile Yet? Abby Fichtner (the hacker chick blog) shares some great tips for team sthat want to be agile.

When Bureaucracy Kills Leadership (and Your Organization) Ronald E. Riggio, Ph.D explains why bureaucracy is bad. I'm sure most of us see it every day - the article is good - hope it reaches those intended.

Conflict is Human: Let's Use It Well Deborah Preuss explains why conflict is good. I agree.

Reference list of Open Space Sessions [Open Space] Last one on SG2010 I promise. this one conatins links to all open space sessions details.

How One Leads Others: Plus It, Always! Dr. Jeffrey Magee on leadership. Looks interesting and I should find a few minutes to read it this weekend.

A video of Professor John Seddon discussing the seminal moments that informed the evolution of his systems thinking method

Weekly agile links 8-12 Mar 2010

2010-03-05T14:35:00.034Z

And here goes another week of hundreds of valuable links flying around.. and I somehow managed to select less than that so they can actually be useful (hopefully).

This week my link of the week is:
Jurgen Appelo's article in defence of Scrum (seriously people - stop pissing on it!)

And all my links below:

Being a Better Team Member Tom Glover gives some advice on being a team member and how to make teams successful

Kanban - The Next Step in the Agile Evolution? Ketil Jensen builds a case for using Kanban over Scrum.

Giving and Receiving Effective Feedback In The Brain of Elizabeth Keogh series by skillsmatter.com. Another presentation provided by SkillsMatter that is definitely worth watching.

90 Minute Agile Sprints and Emergent Design at SnapCamp Another idea for shock-therapy switch to Scrum. I have to try this some day!

Motivating employees without money Ankit Patel proves why Lean organizations are better placed to motivate people and grow.

Are You Managing Resources Or Building Knowledge? Yet another article that outlines the reasons why people should NOT be called resources.

Bring out the best Daniel Schroeder looks at Employee morale in recent times and suggests how to improve it. I wish more C*Os read this.

37signals long term business planning The guys from 37 signals say you should Unplan (similar to Unlearn your MBA) - great one again - Thanks for the link ;)

You rock
Some wisdom from Seth's blog - very short and worth the read.

Tools for Agility and Lean and Kanban Principles for Developers Cory Foy provides two of his recent presentations. Haven't seen them yet and should find the time to do it soon.

Communication Skills Game Another one for the collection. I have seen others that illustrate the same idea (e.g. the telephone game) however I think this one potentially is more provoking so should experiment with it next time I have the opportunity.

9 Questions to assess team structure Mike Cohn suggests 9 questions to help identify if teams are well positioned for success.

[link of the week]
In Defense of Scrum (Please Stop Pissing on It) Jurgen Appelo says a few good words about Scrum (in contrast to all the downsides we've been hearing about lately)

Visions of Leadership Paul Lemberg has many valuable advices on how to stop being Chef Cook and become a great CEO.

Developer Quality! … and Certification? Second article in reaction to Uncle Bob's recent post this time by Ron Jeffries. I have not read it yet so another one in the "to read" list.

Scrum Gathering Collides with Project Management Jesse Fewell with some details from the Orlando Scrum Gathering

Agile or W-agile? Rachel Davis on cowboy agile or as she calls it w-agile.

Balanced scorecard author talks agile business and risk manaement Harvard Business School Professor and author Robert Kaplan discusses how he defines two subjects that are receiving a lot of buzz these days: agile business and predictive analysis

How Much Process Is Too Much? Eric Ries discusses how to figure out how much process startups should have in this article for Harvard Business Review

Agile South Coast: The Next Group Meeting will be on 8th March

2010-02-26T16:51:00.000Z

Howard van Rooijen will be talking about BDD!

Any time left after the talk can be used for networking or open space discussions.

The venue will be the iMeta offices near Southampton

The spaces are limited so please make sure to register at http://agilesouthcoast.ning.com/xn/detail/5068743:Event:139

DATE: 8th March
TIME: 19:00
iMeta Technologies Ltd.
Phi House
Enterprise Road
Southampton Science Park
Southampton
SO16 7NS
United Kingdom
http://maps.google.co.uk/maps?f=q&source=s_q&hl=en&geocode=&q=SO16+7NS&sll=53.800651,-4.064941&sspn=21.245077,42.758789&ie=UTF8&hq=&hnear=Southampton,+Hampshire+SO16+7NS,+United+Kingdom&t=h&z=16

Everyone is Welcome!

Weekly Agile Links 1-5 Mar 2010

2010-02-26T16:04:00.025Z

Overwhelming number of links this week and I had to select the ones I believe were better read. This week my link of the week is Jean Tabaka's list of tips - 78 Things I Have Learned in 6 Years of Agile Coaching

New Site for Agile Managers and Team Leaders Jurgen Appelo introduces a new website - management 3.0

Are tools necessary for acceptance testing, or are they just evil? Gojko Adzic dissects a recent Jim Shore article and defends the need for acceptance tests.

When Agile meets data: a call for longitudinal studies Laurent Bossavit thoughts on Scrum and data from other approaches. I like the conclusion- Agile is a journey of inquiry

[link of the week]
78 Things I Have Learned in 6 Years of Agile Coaching Jean Tabaka and her most valuable advice for Agile coaches - priceless!

Fixing the Quick Fix Esther Derby on fixing the problem and not the symptom. Always worth reading Esther's articles.

Getting Started With Agile (1/5) First of Mike Cottmeyer series on Starting with Agile

A CLEARer way forward Glyn Lumley redefines objective setting and points out why CLEAR is better than SMART

Failure Is Not An Option, It Is A Requirement. Derick Bailey on the benefits of failure.

In Awe of Process Excellence joeely618 tells an experience about learning.

It's The Execution That Matters, Not The Idea This just confirms what I've always said.. ideas are important but execution is more important.

Learning from Dogs Dave Rooney on how precious time is and how you should use it!

What does being a team really mean? Gerry Kirk outlines his definition of being a team. Also touches on the "5 core Scrum values".

Inevitable and avoidable rework Simon Baker talks about two types of technical debt

The Name Game I know another game that goes under the same name so was pleasantly surprised to see that this one is different. Definitely will try it ;)

An Agile Coach to start Scrum Widely in a Company Dimitri Baeli @ agileee2009 (video)

Is there a place for criticism of Scrum? Tim Gregory on what's wrong with most scrum practitioners' attitudes and how Scrum needs to evolve.

Deming’s 14 Points and Quality Project Leadership J. Alex Sherrer explains how to utilise Deming's ideas in practice.

5 Little Things That Make a BIG Difference as a Leader Part 1 Dan McCarthy's tips for Leaders - I will definitely look for the rest of the series.

The Fist Of Bad Management There's plenty of talk these days about what is wrong with traditional management and Bret L. Simmons summarizes most of the main points.

Weekly Agile Links 22-26 Feb 2010

2010-02-19T16:50:00.030Z

This week my link of the week is JOHN BRAMBLITT – THE BLIND PAINTER

I've got plenty of other links that you will hopefully find useful including one that is almost 10 years old, some wisdom from Martin Fowler and Cory Foy's thoughts on the new Scrum alliance.

Enjoy ;)

If you haven't watched this yet - you have to do it now!(Seriously man! It is just a bit of dancing...)

Systems Thinking, The Vanguard Method and Software Development Karl Scotland shares his thoughts on the Vanguard method introduce by John Seddon in his book “Freedom from Command and Control“.

[link of the week]
JOHN BRAMBLITT – THE BLIND PAINTER An inspiring video! Shows what once can do if he is truly up for it despite such a huge impediment as being blind. Lot's to learn from this John Bramblitt!

In Praise of Middle Management Peter Stevens says Middle Management is not redundant in Scrum, instead it is the true source of leadership.

Pair Programming: In interviews Mark Needham on Agile approach to interviews. Very interesting - I wish I can attend one of these ;)

Managing in Mayberry: An examination of three distinct leadership styles This one I definitely should read (not just because it is almost 10 years old). It is a little bit long for the time I have so will require some extra effort ;)

Using Agile Techniques to Pay Back Technical Debt I can't believe this! No, seriously -Microsoft start talking sense! Finally. Remember a link to a PM/PMO lady from MS and her experience with agile? Now, there is another MS guy talking about technical debt.. There is hope I tell ya!

Conversational Stories Martin Fowler hits the nail on the head as usual - a good reminder about PO/Team relationship and how user stories should be created.

The Lump Of Coding Fallacy Interesting thoughts on how to change well known habits around unit testing and those opposing to it also about development in general. worth reading ;)

Leadership Books list by Hugh Ballou

..but if the Scrum Alliance Can’t Do It, Who Will? Cory Foy on the SA, the new Scrum and a few opinions of what they should become. Interesting overall.

The Value of Lessons Learned “Experience is inevitable, learning is not.” says Nancy Dixon - contains some good reasoning behind having retrospectives

Great Minds Don’t Think Alike - Ray Silverstein on leadership and building culture of people not afraid to state what they think (e.g. free of politics) - not directly agile and still lots to do with it.

There's more to done than the green dot Interesting thoughts on when is a story really done..

A simple measure of effectivenes Another one from Simon Baker which looks very interesting to me as it is related to agile metric which I blogged about before

Weekly agile links 15-19 Feb 2010

2010-02-15T12:15:00.019Z

Not the best week with regards to links as I was away on training and ill so have probably missed a lot of useful stuff on twitter and the mailing lists.
Anyway I think I still have a useful bunch of links with my favourite being the Leadership Lessons from Dancing Guy Derek Sivers's blog - a truly inspiring video!

All links below - Enjoy ;)

Why Good People Skills Matter in a Recession From Gill Corkindale posted on the HBR blog

Leadership Tools an article by Hugh Ballou

Cumulative Flow Chart in Kanban: Real Usage Example Michael Dubakov demonstrates how a CFC can be very useful.

A Lesson in Getting Started... A real life example that relates well to agile by Mike Cottmeyer

The Tyranny of "The Plan" Always worth listening to what Mary Poppendieck has to say!

Testability & Good Design from George Dinwiddie’s blog

No One Knows What the F*** They're Doing (or "The 3 Types of Knowledge") A very interesting read about the types of knowledge by Steve Schwartz. I definitely need to re-read it if I want to find out more about what I do not know!

A times article by Sathnam Sanghera which has a lot to do with the effectiveness of BBC - hey it is our money they're spending after all!

[link of the week]
Leadership Lessons from Dancing Guy Derek Sivers's blog - a truly inspiring video!

Structure? The Flatter, the Better An interview with Cristóbal Conde, president and C.E.O. of SunGard conducted by Adam Bryant.

Refactoring A guide to refactoring

Relax, Agile Development IS Growing Up A review of this article by Michael Dubakov, lots of points that I agree with

Weekly agile links 8-12 Feb 2010

2010-02-06T12:26:00.020Z

My agile link of the week this time is Matthew Baker's guide from waterfall to agile! [the first link below]
I also have a quote of the week which sounds as valid as ever:
"we're so similar in our attempts to be different"
I hope you enjoy the collection of links!

From Waterfall to Agile: How we got there - Matthew Baker provides a nice overview on the difficulties and challenges while helping a company become Agile.

The speaker interviews: Esther Derby A fresh interview with Esther Derby. A must read although I have not done it yet.

People Are NOT Resources This is exactly what I needed. While I have read bits and pieces about why it is a bad practice, this article gives so much reasoning that I can see myself easily convincing event the worst cases that I know ;)

Lessons from Target Value Design Introduction to TVD by Hal Macomber

Who are your Users?
Liz Keogh on org. structures, stakeholders, users and project experience (interesting read)

Brain Functions That Improve with Age Another great (and encouraging) article from the blogs @ hbr

The STC magazine has arrived! The new magazine for testers published by Rob Lambert (and others)

Pursue the Goal Not the Method I've been trying to say just that! And while a few a prepared to listen I love the fact that others think the same.

The surprising truth about what motivates us An audio recording of Daniel H Pink speaking about what motivates team members

Don't just interview new developers. Audition them! I cannot agree more with all this articles says!

Comparing Velocity Across Teams Vikas Hazrati provides good reasoning why it is a bad practice.

Is the Microsoft Way counter-productive? "Innovation can only thrive where competition isn’t dominant" says Alan Cooper

Work isn't your dad interesting read and the conclusion is similar to one of my friend's favourite phrase - "life's simple - you either collect gold or experience" (like in his favourite game)

Facilitating High-Emotion Retrospectives An alternative approach to Retrospectives by Cory Foy

Revisiting and Re-reading Dr. Deming’s “Out of the Crisis” A must read (at lest to me ;) )

Weekly agile links 1-5 Feb 2010

2010-01-29T16:14:00.025Z

Another week of too many links to go through and pick the ones that look most interesting. This week my link of the week is Sara Ford's (Microsoft) blog post:
How I Learned to Program Manage an Agile Team after 6 years of Waterfall

What does a ScrumMaster do? Nice, short list and a great reminder by Dr. German Sakaryan

10 questions to choose candidates - A useful guide on how to Choose Quality Candidates/Consultants for Your Large Company Agile Initiative

Splitting user stories by David Draper - always worth reading Dave's posts!

Yanking the value chain Ade McCormack thinks there are some worrying omissions that could threaten the success of the IT function

EPIC goals of coaching Useful summary on coaching types by David Harvey

The Cost of 2nd Time Quality
To be honest this is far too long to read but it looks promising and has lots of data and pretty pictures ;)

Adopting Agile Development - The role of the CIO Isaac Sacolick on how the CIO changes during agile adoption

Why Work should be fun A post (or perhaps a rant) by Felicity Goodey

They’re not User Stories To find out what "they are" check Liz Keogh's blog

Mockups with Balsamiq I have heard about balsamiq several months ago and since then I see more and more people using it for UI mock-ups. Great summary by David Draper

Building a Requirements Foundation with Customer Interviews by Esther Derby and from the The AYE Conference

What Really Motivates Workers by Teresa M. Amabile and Steven J. Kramer and from the HBR (with the usual quality)

Pragmatic Personas: Putting the User back in User Stories Jeff Patton reviews the different ways that software is currently built.

Can Scrum Support Six Sigma? An attempt to combine these two by Heitor Roriz Filho

[link of the week]
How I Learned to Program Manage an Agile Team after 6 years of Waterfall Some good insights that could help traditional PMs to transition to agile by Sara Ford (and also some shocking news about the dev tools we use on the MS platform)

Barry Schwartz on our loss of wisdom Barry Schwartz makes a passionate call for "practical wisdom" as an antidote to a society gone mad with bureaucracy.

Weekly agile links 25-29 Jan 2010

2010-01-21T10:53:00.018Z

This week I will begin with my quote of the week. And it comes from Alvin Toffler who says that: "The illiterate of the 21st century will not be those who cannot read and write, but those who cannot learn, unlearn, and relearn". Feels about right, doesn't it?

My link of the week this week goes to Unlearn Your MBA Podcast with David Heinemeier Hansson (of 37 signals)

Here are all my agile links this week:

Sum Up Your Leadership in Six Words This one sounded interesting and in fact the entire blog of John Baldoni is worth reading!

Agile Toolkit podcast Plenty of interesting topics there!

John D.C. Little and Stephen C. Graves - Little's Law about metrics.

Are We Agile Yet? Bob Maksimchuk on big boss attitude towards becoming agile.

Version One;s Agile Salary Results Time to look at the job boards or to keep quiet? ;)

How to Foster A Culture of Innovation - Moving Beyond Pull Systems Requires a Culture of Innovation says Ryan Martens

[link of the week]
Unlearn Your MBA Podcast with David Heinemeier Hansson (of 37 signals)

New to Agile? Want to know which tool to use? Blog post by Alan Kelly that recommend avoiding tools

Go-Givers Sell More: Free Introduction and Chapter 1 from Bob Burg and John David Mann's book. Very interesting read by the looks of it!

The Necessary Conditions for Behavior Change - Ken Nowack on Change

Interview on Daily Stand-ups - Henrik Larsson interviewing Jason Yip (Thoughtworks)

Non-Functional Requirements: do user stories really help? A video with Rachel Davis

The heart of Lean - "Thinking for yourself in your context" - extremely good read spreading lean wisdom and coming directly from Toyota and the TPS.

The ScrumMaster Diaries: #3 – Becoming a CSM great post highlighting important issues about by "Agile Bob"

My weekly agile links 18-22 Jan 2010

2010-01-15T16:21:00.021Z

Wow! What a week in terms of links flying around (I'm sure it is because it was my birthday during this week :) ). Out of these I could easily choose a few favourites but in the end it has to be one so this week's #my link of the week is Bill Wake's Scrum Development on a Page. Enjoy!

And here are all my links this week:

A post by Andrew Carey, caught my eye because it mentions John Seddon and I've been impressed with his talk from last week. The title is "Tick Box Britain"

Sometimes, Agile Alone Isn't Enough - Mike Cottmeyer on agile and the organization although to be honest is mainly about some/his book (apart from the diagram - I like that one)

Michael James's article in Better Software on Scrum and organization bariers to implementing it.

Henrik Kniberg advises us to stop comparing Scrum & Kanban to find out which is better. they both can be useful .. just like a fork and a knife - Kanban's Not Better than Scrum, It's Just Smaller

Roman Pichler's blog on Product Ownership (It was about time someone clarifies it - Thanks Roman!)

Scaling Software Agility: Best Practices for Large Enterprises - Presented by Dean Leffingwell

Selforganisation and Type of heat - this one's said to be inspired by Jo Pelrine's talk about head which I attended last May during #acg so I thought it must be interesting.

Lifehacking: Applying a Geek Concept to Advance Your Personal Growth I actually read this and it sounds very geeky + all the ideas about self improvement in different form.

Why Prioritizing Your Product Backlog for ROI Doesn’t Work - blimey read this one as well.. some good ideas but to me very similar to a prioritization excel spreadsheet I've been using over the last 2-3 years.

Scrum Development on a Page A good summary of Scrum on a single page (by Bill Wake)

Improving Software Economics - 10 Principles for Achieving Agile Software Delivery This is very interesting - IBM starting to talk sense. Well almost - I still sense a fair bit of overhead in these principles. Overall though a few interesting points that show these guys are beginning to listen.

Ability to manage change ‘marks out successful organisations A study that says client needs and not costs should drive change.

Scrum Anti-pattern : Prioritizing Stories Within Sprints Some call the Scrum Smells.. in any case things you should not do and if you have a few of those you might need to reconsider how productive you are?!

My weekly agile links 11-15 Jan 2010

2010-01-13T10:10:00.021Z

Wow.. A very active week as you can see by the number of links. This prompted me to start doing #my link of the week. So here's my first ever link of the week:

Carl Sagan - Pale Blue Dot
3 mins and 31 seconds worth sparing for this video. (WARNING: You may spend the rest of the day rethinking your life)

All weekly links:

Simple Scrum - another good article by Tobias Mayer describing the basic Scrum excluding any software development specific terminology

The extended family of Agile A survey, the results of which we have seen in many presentations, so good to look at the actual data.

Agile Coaching Tips by Rachel Davis - a very very good bunch of techniques and advices

The Agile Coach Manifesto - Jason Little's proposal for Agile coach manifesto

Five Disconnects of Organizational Intelligence Demanding Change - RICHARD VERYAR's blog

Defending Leadership an article by by Mike Myatt, Chief Strategy Officer, N2growth

Creating Useful Measures David Joyce on measures for continuous improvement

Mind your business - Marketing your business (very similar values)

Re-thinking Lean Service Inspirational speech full of truths about services by John Seddon

Mike Cottmeyer on Agile Project Management, Building Effective Teams

BDD & DDD - Dan North presents Behaviour Driven Development and Domain Driven Design

Carl Sagan - Pale Blue Dot
[Link of The Week]

“Why Lean and Agile Go Together” on Forbes.com

Theory of constraints for beginners David Draper's blog

Weekly agile links 4-8 Jan 2010

2010-01-08T14:05:00.005Z

Now that is a hell of a promise ;) I find out that the list of links that I open rarely stays for more than a week so it made sense to me and I am fairly sure in the near future I will have to dump these links somewhere. So here goes:

Mike Cohn's The Role of Leaders on a Self-Organizing Team

A reminder of what retrospectives should be like - A Retrospective Agenda

Scott Berkun's blog - Why do big companies suck?

The F# Survival Guide (I know not really an agile link but still of interest)

A book I am buying - The Beermat Entrepreneur: What You Really Need to Know to Turn a Good Idea into a Great Business

Two simple questions (very much retro style)

That's all I have this week, have a good weekend ;)

Agile links #4

2010-01-05T13:47:00.002Z

This set I am afraid will be shorter than expected although it comes 2 weeks later than the last one but it was the holiday's period after all ;)

Tobias Mayer's blog - It starts with belief

David Joyce's talk - A Journey to Systemic Improvement

EMC blogs - 100 job search tips

Evolving Excellence Flexibility: A License to Accept Waste

Bruce Eckel - Wrong Correctness

The Content Economy - Did you ever hear anyone shout "culture failure!"?

Fast forward blog - Employee Engagement – a Core Goal of Enterprise 2.0 Adoption?

Agile links #3

2009-12-24T21:39:00.002Z

David Joyce's - A Journey to Systemic Improvement video link here

Mike Cohn - Synchronize Rather Than Overlap Sprints

It’s Not the Recession, You Just Suck

Moon Shots for Management Or Management 2.0 and its grand challenges Pdf link

How GANTT Charts could be built by using LEGO!

"You don't find customers for your products. You find products for your customers."

Agile links #2

2009-12-22T08:25:00.003Z

Quickly after the first post here comes a second set of links:

Mentoring of candidates for CST many people have asked in the last year how to become a CST and here are the answers. Note that This is NOT an official set of requirements for CST application

Safecracking for the computer scientist Computers & security - by Matt Blaze

This is not like That Another (I am sure) brilliant post by Tobias Mayer which is in fact a repost of Lyssa Adkin's original post.

MANAGER 2.0: THE ROLE OF THE MANAGER IN SCRUM by Pete Deemer

Tester Types A humorous look at the different testing types according to Rob Lambert

Integration Management an interesting post on the PMI Agile Community of Practice Wiki which for some reason links one of my articles.

Agile links #1

2009-12-18T08:51:00.007Z

There is something about all the links to blog posts, articles, videos, etc. The information these sources have is usually very interesting. At the same time I find it more and more difficult to find enough spare time to read them all. I have tried emailing links to myself, tweeting to myself and many other tactics with mixed success but mainly no success ;). So Now I decided to stock them here on my blog so I have the links without growing my bookmarks to unmanageable level and still am able to access the links later when I find a few spare minutes. So here goes agile links #1:

People Polling @ tasty cupcakes

Systems Thinking: The Fifth Discipline of Learning Organizations By Marty Jacobs

Leadership and systems thinking.

Presentation Tip: How To Tell A Story

5 Secrets to the Hidden Job Market

Abolishing Performance Appraisals - a book I might buy
The Airplane Game - A pratical introduction to Agile/SCRUM

Notes on Starting an Agile User Group

100 Impediments A look at impediments a team may need to address.

That's all I have for now.. I hope this might be useful for someone else as well ;)

Agile Works (exclamation mark)

2009-12-04T15:31:00.004Z

Not that you'd doubt it if you've seen both sides of the coin.. but this is just the icing..

If this is not proof that agile really works and is your best shot then what is?

Just another evidence that unwillingness to do Agile is as good as acknowledging that you don't want to improve and you don't care at best?!

Read the full story here

DEMING'S RED BEAD Experiment Replayed

2009-11-19T13:13:00.000Z

I recently became aware of this experiment which Deming used to do in front of large audiences (e.g. 1200 people). Thanks to David and Benjamin the experiment comes to live again. It is worth watching at least the first 50 minutes and see for yourself this amazing story of processes, metrics, management, rewards and people.

http://skillsmatter.com/event/agile-scrum/demings-red-bead-experiment

The Cool Wall Retrospective

2009-11-06T11:10:00.006Z

Inspired by Mark Summer's post we decided to do a Cool Wall style joint team retrospective at the end of last sprint. These are scrum teams that work on the same project and often have cross team impediments or reasons to be proud.

It worked quite well, team said they liked it so we're doing it again. For more details on the technique check Mark's blog here

CSM course in Bournemouth 23 & 24 November

2009-10-30T13:18:00.001Z

Geoff Watts will be holding a CSM training course in Bournemouth on the 23/11/2009 and 24/11/2009. For full details see here

Scrum and Agile metrics follow up

2009-10-13T16:18:00.003+01:00

While looking at metrics and what is appropriate I finally came across something that made sense to me and to the scrum masters in our department.
The information is from an article by Michael James which doesn't seem to be available any more unfortunately. The title of the article is An Agile ApproAch to “Metrics” and you may try to find it if you're more persistent than myself.

This article suggests to use a combination of 3 or 4 metrics. While I generally like the idea I am not sure all of them would work in our current environment. For example I would avoid using velocity in that sense although I would use it as a trend and not really related to the reports that Senior Management wants to do.

The two things that I reckon make sense are:
1. Delivered business value - i.e. every item has a business value and you count how much is being delivered
2. Running Tested Features which is something Ron Jeffries talks a lot about and we happen to do - e.g. a feature is RTF if it can be demoed from production build and passes automated tests (which should cover the acceptance criteria).

These two in combination make it difficult to game and also guarantee both business value and quality. While I am sure some people can still game them, I believe they represent a reasonable way to resolve the metrics problem.

Agile metrics / Scrum Metrics

2009-08-11T10:10:00.004+01:00

I very often hear about metrics in agile or what metrics shall we use in Scrum?
I recently came across Mary Poppendieck's suggestion about using the following "holistic measures":

1. Average Cycle Time – how long things take to go through the system.
for example - requirements from capture to acceptance and defects from
detection to correction.
2. The Business Case – Is the project still viable? If this isn't the case,
everything else is irrelevant.
3. Customer satisfaction – are your customers happy?

I wish I could try these one day.. instead my managers ask me to calculate the time spent on stories/projects and all types of coverage reports. Oh well.. ;)

Twenty tips to write a good stored procedure (RB)

2009-08-10T10:45:00.002+01:00

I came across a very useful list of tips for writing good Stored Procs by Arup Chakraborty here

I would say it can be combined with my set of best practices to include things like limiting the sets as early as possible.

Good read overall!

The Wessex Scrum User Group

2009-07-17T09:07:00.004+01:00

Our local Scrum User Group based in the South of UK has a new name - The Wessex Scrum User Group!

After months of exchanging emails with the Scrum Alliance, talking to the guys from the London Scrum User Group and discussing how to recruit more members we finally agreed on a name, the SA published our group profile here and we can also list all our events. We also have a new SA designed logo and some arrangements are in place to get experienced people (like CSTs) to visit us!

We have not yet created any website though and the only group place on the web is still the linked in group. Hopefully this will be the next thing on my list after the holiday season.

In the meantime looking forward to the next few meetings, especially the August one when we'll have a special guest - Geoff Watts! Also something to think about is the London Scrum Gathering in Feb 2010 which we may get involved in by contributing to the program and the organization.

Hope to get a good rest next week, as with Scrum Fest and Ken's visit last week it has been quite hectic.. not to mention the kick-off of the new project at work.

Do something S.P.E.C.I.A.L.!

2009-06-18T14:21:00.004+01:00

Scrum – Start sprinting, there is no faster way to fail and then correct the problems and then do it again to achieve continuous improvement.

Positive – You have to maintain a positive attitude. Accepting change isn’t easy for most people and there will be some that may find it difficult to adapt. Learn enough to be able to explain a lot but also continue reading and finding answers as you go.

Effort – you need to make an effort to make this work, and not only you. Everyone on the team must get out of their comfort zones and start thinking on how to improve every single detail of what they do. Many Scrum books recommend as a prerequisite having the right people and the right people must have the right attitude and be able to make that extra effort to succeed.

Communicate – communication is a key factor in the success of every agile transformation. Make sure you remove all barriers that may prevent communication. These could range from cubicles to avoiding conflict. You may need to learn a lot about dysfunctions and how to cure them and you may need to participate in difficult discussions with facilities managers. But without doing it you will be reducing your chances to succeed.

Inspect – regularly look back and think about the things that you did well and the things that you have to improve. Find a good retrospective technique that works for your team and make sure you look not only within the team but also for organizational barriers.

Adapt – identifying the issues would not be worth the effort if you’re not doing enough to resolve them. Things that slow you down should always be near the top of the list for stuff you need to do. Add them to your backlog and make them visible – this is an effective way to get them resolve and then identify more issues.

Learn and listen. Never stop learning, learn from mistakes, from the experience of others, from the people you coach and teach. Learning, just like improvement, never stops. Learn to listen, because the moment you started this transformation you’ve become destined to coach and coaching is all about listening and asking the right questions to help people around you do better.

Are you ready to do something S.P.E.C.I.A.L.?

Effective coaching styles

2009-06-10T15:04:00.002+01:00

Open space session notes from the Agile Coaches Gathering 2009 (Milton Keynes)
Key info:
- Facilitated by Xavier Quesada Allue
- Attendees that I remember: Rachel Davis, Manish Shah, Bob Marshal, David Draper, David Joyce, Manav Mehan (and many more + I hope all these guys really were there)

First we listed styles that we can think of including:
- Non directive style
- Leadership style
- Depending on what the person expects (adaptive)
- Trainer style
We recognized the fact that there are dimensions and styles. We looked at established coaching models like GROW (Goal, Reality, Options, Will), The Dreifuss model, The solution focus model based on getting the goals out of the coachee.

Then we talked about capability coaching and the thoughts I listed on this were various approaches and questions to ask like:
- Interesting! Tell me more? (instead of reacting negatively and directing)
- Why? – Perhaps replace with “what would that give you?” or “what would that result in?”
- What value does that give us? Is that what we want?
- Get going (not sure about this one, perhaps related to do and then inspect.)
- Look at all the issues (e.g. impediments, problems) and prioritize – perhaps phrase this as question

Somebody asked the question – Do you have to have all the styles? And the answer came that you certainly need a set of styles. How do you find out how effective your style is? Watch other people coach in action (Shadowing; Pair-coaching).

You need to ask yourself the questions – Who you are being and what you’re doing. You can have the same or different model and perhaps slightly different style.
You may want to think about 3 adjectives that you would use to describe this person like best at? Or worst at?

How to find out if you’re effective? Can remote coaching be effective? You rely on hearing only and lose the body language. Near coach/far coach model.

Coaches should not be part of the system – if you are then you’re missing coaching opportunities. Your goal as a coach should be the improvement of the team.

The team must respect you. You have to be visibly doing stuff. If you quickly show/add a bit of value then you get respect. You also need to show respect. Consider if the team has actually asked for a coach?
[An interesting related book is “The speed of trust”]
There are 3 factors:
- Character
- Competence (It has been noted that it is easier to coach if you’re less competent as you do not direct)
- Consistency (develops over time and sets predictable behaviour)

For example coaching a tester can be effective even though you don’t know anything about testing.
You perhaps need some basics – e.g. TDD, principles, knowing concepts and tools.

Coaching is to help someone move forward.

[A good book to check is Quiet Leadership.]

Value, Flow, Waste

2009-06-04T23:02:00.007+01:00

I heard somebody talking about these three in the same sentence a couple of weeks ago and accidentally (or perhaps now) used them in a presentation draft while trying to explain what in Scrum we'd separate as functional/non-functional.. and waste although it doesn't seem to come up that often as the other two.
Anyway so I had to explain what it is as the word Value seem to be causing hiccups with some of our managers and the shorter explanation I could think of was that value is what we get money for, flow is what makes possible the production of value and waste is all that doesn't add to any of the other two so we throw it away.

I then ended up searching for more info and discovered 5 principles of lean (as opposed to the more famous 7). Here they are:

1. Specify value
2. Identify the value stream
3. Make value flow
4. Let customers pull
5. Pursue perfection (e.g. identify waste and eliminate continuously)

Ok, so the connection is that these 5 principles well explain the title as well and I am going to use them when I talk about it in about 10 days time. I may even post something about the event as it is my first ever agile project initiation boot camp.

MCIF or beware - IBM now wants to make money out of agile!

2009-06-02T22:00:00.003+01:00

After the big guys realised there is no way RUP can deliver as well as what can be described as naturally evolved and community driven agile frameworks like Scrum and XP they now seem to have decided that at least they can save their reputation by switching to agile but they also want to make money by using the equivalent of open source development approach.

I feel really sorry for the people that will spend money on this just because it comes from ibm. As before they'll stick with it for a while until the community moves forward and discovers something better. then ibm will go away and come back with another "clever" abbreviation.

Do not spend big on agile transformations. money will not give you productivity, not from such big companies anyway. speak to people in the community and you'll soon get a good recomendation of a successful coach or even a consultancy. As for IBM - yeah good luck with that.. I predict another RUP-like story...

Unit Testing ASP.NET? ASP.NET unit testing

2009-05-21T11:41:00.002+01:00

Typemock is launching a new product for ASP.NET developers – the ASP.NET Bundle - and for the launch will be giving out FREE licenses to bloggers and their readers.

The ASP.NET Bundle is the ultimate ASP.NET unit testing solution, and offers both Typemock Isolator, a unit test tool and Ivonna, the Isolator add-on for ASP.NET unit testing, for a bargain price.

Typemock Isolator is a leading .NET unit testing tool (C# and VB.NET) for many ‘hard to test’ technologies such as SharePoint, ASP.NET, MVC, WCF, WPF, Silverlight and more. Note that for unit testing Silverlight there is an open source Isolator add-on called SilverUnit.

The first 60 bloggers who will blog this text in their blog and tell us about it, will get a Free Isolator ASP.NET Bundle license (Typemock Isolator + Ivonna). If you post this in an ASP.NET dedicated blog, you'll get a license automatically (even if more than 60 submit) during the first week of this announcement.

Also 8 bloggers will get an additional 2 licenses (each) to give away to their readers / friends.

Go ahead, click the following link for more information on how to get your free license.

South UK Scrum User Group, 27th April 2009

2009-04-29T12:52:00.001+01:00

Getting an acceptable definition of done

[Notes from 27th April 2009, South UK Scrum User Group]
The level of granularity is important, which is why we define the definition of done at four levels: release, sprint, story and task.
At the task level we look at the following:
- Developer says it is done
- Unit test exists and passes
- The code is in the trunk
- Code coverage is above the target (e.g. 90%)
- More criteria can be used as function points, analysis coverage, cop type coverage
- Tracking system is updated
- Check-in is reviewed
- The work is reviewed
At the sprint level we define the following:
- All agreed stories are done
- Held a retrospective which is documented
- Show and tell demo
At the Release level the criteria are:
- All sprints are done
- Media is produced (e.g. CDs, marketing materials)
- User documentation has been reviewed (e.g. by the user community)
- Install and release notes are ready
- External testing or audits are performed (e.g. security audits)
- PO signs it off
The definition of done for Story include:
- All tasks associated with the story are done
- The story is integrated and tested
- Acceptance criteria is met
- Installation works
- Documentation is done
- Product owner accepts the story

First UK South Scrum User Group Notes

2009-03-20T10:18:00.005Z

On 18th this months in a nice pub in Ringwood we had the first ever UK South Scrum User group meeting.

I tried to take as many notes as possible for the benefit of the group members and hopefully the entire Scrum community.

Here's what I managed to write down:

What do we want to achieve with this group?
- Get people to come along and chat (about Scrum and Agile)
- Meet once a month every 3rd Tuesday (this has not changed to last Monday of the month)
- Talk about common issues and ways to resolve them
How do we do it?
We will experiment and pick one of the following or perhaps something else if these are not suitable:
- Open space discussions
- Goldfish bowl
- World cafe
How do we make people aware about this group?
- Ask people who do training for contacts
- Blog about it
- Announce it to NextGen members
- Make it regular – regular day and location
How big do we want it to be? The bigger it is the more structured it has to be.
- Could have perhaps a “learn about Scrum” session
- Talk to big Scrum/Agile consultancies like Conchango/EMC or RallyDev about sending speakers.
- Clive and Plamen to talk with Roman on 8th April (London Scrum User Group) about getting the group listed on the Scrum Alliance website.
We then talked about the biggest challenges that each of us recognises. I have recorded hopefully most of these:
- Getting acceptable definition of done – everyone to sign up for it [This has also become the topic of our next meeting on 27th April)
- Guiding/Coaching ScrumMasters that are new to Scrum and making them become Scrum advocates
- Getting full Senior Management support in a big organisation
- Change process as a whole and trying to implement it into large organisations
- Requirements – getting the definition of them, making them agile requirements.
- Technical gold plating – when to do just enough architecture, design ,etc.
We then went on to talk about positive experiences and again I hope I recorded most of them:
- Team refused to estimate as no answers were given to important requirements questions
- Team no longer delivers the wrong solution
- Team response to HR attempt to impose individual performance reviews.
- Team managed to isolate maintenance to overcome problems with delivering
- The “War room” and winning it from the business just for Scrum use by the teams
- Throwing away the concept of in-sprint defects and no longer wasting time to log them into some system. Get the testers talking rather than typing.
Other thoughts or discussions were around:
- Getting people to understand what is realistically done and optimistically done
- Tech authors could be key as while wanting to know more they lead the information sharing and steer teams towards delivering the user stories
- Important thing is to have the right ratio QA/Developers
- Tools in use include: Rally, TFS, Version One, Target Process (also has helpdesk) and xProcess.

Overall a very good evening and lots of ideas have been discussed. We also managed to set up date for the next meeting, agree on actions about making people aware about the group and identified the main topic for next time.

I hope to see you all there and hopefully a few more people will turn up as well!

Scrum User Group in the South (outside London)

2009-02-12T12:02:00.004Z

A fellow scrummer based in dorset has posted this yesterday and emailed the scrum development yahoo group with an idea to organise Scrum UG in close proximity to BH, SO, PO. I then decided to join him in an attempt to gather enough people and created this linked in group. If you happen to somehow find this post and live in the area and are interested in participating in a Scrum UG please join the linked in group.

Ron Jeffries answering 5 Scrum questions

2009-01-27T08:42:00.002Z

I always enjoy reading Ron Jeffries' posts and they are one of the reasons for me to subscribe to as many agile yahoo mail groups as my mailbox is comfortable with.
So when I found, this short interview I thought it is brilliant, just like reading about 10 posts at once which usually means lots to learn from a great agilist in just a few minutes of reading.

Въведение в Скръм (IntroToScrum) на Български е публикувана!

2009-01-21T14:32:00.004Z

След много дълго продължил превод и доста по-бързо направени ревюта от:
проф. Аврам Ескенази
и
Георги Стойчев
успях да направя корекциите и изпратих първия вариант на презентацията която Майк публикува вчера на този адрес.

Междувременно се оказа че има още желаещи да помогнат с подобряването на превода така че скоро ще има обновена версия.

Много се надявам това да се окаже полезно и да допренесе за популяризиарнето на гъвкавите методи и в частност Скръм в България.

П.С. Това ми е и първият постинг на Български ;)

Scrum Gathering Stockholm 2008: Day 1, More afternoon sessions

2009-01-12T11:25:00.005Z

(I am) terribly late again... but I am sure I still have a chance to finish publishing before the next gathering takes place (hopefully).

I chose to attend a session about the Scrum Implementation at Man Investments. First thing to notice was a guy that looked very familiar to me... so familiar that I later on went to speak to him but it turned out he just reminds me of someone but he is not that guy.. Anyway the presentation was great, mainly because it was by a UK based companies so they seemed to be facing pretty much the same cultural issues as we do. They seemed to have obtained better support on director’s level and also have spent extensively on Scrum training. Unfortunately the last is not something I can hope for.

I thought it is worth noting that they managed to get an actually business analyst to be the product owner of one of their teams and even better the guy was there and spoke a little about his experience. Apart from being a typical *business* type (e.g. would try to sell you anything) he left me with the impression that he actually “got it”. And he also hit me with another sad reality thing – they did Scrum training for the business side... something that in our company would be a huge struggle to do... I guess again it is down to the level of support from the C*Os.

Something we now beat them at was the integration; they stated they integrate every sprint while in fact we strive to integrate every day or 2 days max. And for the first time I’ve heard about real experience in a joint planning session where you have more than one teams working on the same backlog. I would imagine that is a bit difficult to manage but for the time being we don’t need to do that.

And they carried on presenting more and more useful tips like the code coverage metric which we are now trying to introduce, user stories workshop with the business involved - not that we don’t know about it but again how much support is needed to get that done?! Good suggestion was the fact that they allow about 10 points for technical debt when trying to improve existing legacy code. This alerted us to something but we try to estimate the non functional work and add it to the backlog – we came to conclusion that this makes more sense.

On the last session for the day the speaker actually didn’t turn up so we had a discussion where Robyn Dymond initiated the format of having a 3-4 chair panel in front (as if they are the speakers) with the simple rules that only when all chairs are filled with people and only people sitting in front can speak. It was a valuable experience and I wish to try this format soon. We discussed many issues including how to ensure team does not become stale, how to sustain improvement and others.

Overall it was a great first day that ended with a rather weird sponsor cocktail but if we were to ignore all the talking the free beer and decent food were good enough reason to spend some more time in the conference building.

Scrum and The Enterprise (Panel - Day 1 afternoon)

2008-11-25T11:22:00.004Z

In the afternoon of day 1 I chose to attend a discussion about Scrum and the enterprise with Bas Vodde, Steve Greene, Nigel Baker and Robin Dymond. I found it very useful as I am interested in applying Scrum for large scale projects and organisations. Unfortunately my notes from the session could have been a lot better but I focused mainly on listening and therefore it took me some time to connect all these notes in my notebook.
A book by John Kotter has been mentioned with title “Leading Change” which was recommended as useful read for discovering and being aware of 7 key errors in the process of change (I intend to buy it). Bas said that Nokia scrum implementation was a bottom up one which I found interesting as I always thought that such a large scale change must be driven from the top. A couple of the speakers agreed on the advice that coaching should be done on the basis of one person at a time and this is one of the reasons that changing the organisation is slow. Somebody said that culture and cultural change is overestimated. A key thing is to make sure testing drives development rather than waiting for story completion.

An interesting topic was how to do planning when teams have many related functionality and dependencies. The suggestion was that all dependencies are displayed on a white board and teams then link with other teams and list commitments. When you have such a large implementation you end up with many teams, the scrum masters of these teams form teams as well and they have scrum masters as well which is a reason for having the 3S meeting(Scrum of Scrum of Scrums) which was recommended to be done once per week.

In terms of keeping team members engaged it was suggested doing regular innovative workshops which should include the business owners and also having OpenSpace days to raise Scrum awareness and to support the coaching community. In terms of working with HR the advice given was to have Scrum roles – Scrum team member, Scrum Master and Product Owner and define competencies for these roles. I guess the challenge is to convince HR and Senior Management that this is needed.

There was the inevitable question about architecture. The common opinion was that architecture is best to emerge – Google walking skeleton.

A huge importance is being placed on having a skilled Agile Coach not just a volunteer. I would say it is the same with Scrum Masters and Product Owners. It is difficult to ask people who are not passionate about Scrum to show the same energy and engagement and deliver the same leadership as an experienced and successful practitioner.

Somebody also said that while agile coaches are skilled change agents, traditional PMs are only skilled to tell lies ;)

The change to scrum is a change from activity based hierarchy to value based streams. For the enterprise it was suggested that Scrum/Lean combination makes sense. Scrum provides the tools; Lean makes sure waste is eliminated.(or so my notes say).

Scrum –dominant in the Agile Community

2008-11-07T12:12:00.002Z

(Day 1 of Scrum Gathering Autumn 2008)

Jeff Sutherland started the day with a resourceful session about the long way Scrum has gone to become the dominant agile approach. Following are my notes so most of the information comes directly from Jeff except where notes weren’t enough I tried filling in the gaps. If you find some of this confusing it is because of me ;)

Interesting facts in the presentation included results of a research showing that 49% of Agile implementations are Scrum based and another 22% are Scrum/XP. Jeff also touched on productivity improvement levels and how Scrum adoption can affect them. For example an excellent Scrum implementation should result in 400% revenue increase; Good Scrum would give about 300%; Pretty good about 150-200% and something he called ScrumButt just mere 0-35%. Just for clarification ScrumButt also referred to by other authors as MURSC, ScrummerFall, and others is an implementation that doesn’t fully follow the rules of the framework and as result this affects the level of productivity and profitability increase.

I liked the suggestion about what kind of goals work better. I am sure many company directors or owners will say their goal is to meet revenue targets. In fact goals that are likely to work better should focus on customer satisfaction and employee happiness like for example “customers to be ecstatic” or “make life of employees better”.

One of the biggest problems during adoption phase is the fact that traditional managers and often the whole institution have problem with self-organizing teams. They’ll try to do control planning which kills self organization. They find it difficult to abandon command and control which is likely to crush the team. They carry on doing isolated activities and promote lack of transparency which undermines self organization. They object impediments removal which delays progress. So no wonder why 70% of change initiatives fail! This highlights a bigger issue – lack of sense of urgency among leadership.

Jeff suggested using the enhanced Nokia test for finding out if a team is doing Scrum or not. There has been a vast discussion on scrumdevelopment about how and if such tests are useful and while generally I do not like the idea of measuring using the enhanced test for initial assessment seems a really good approach.

A look into the most productive ever projects (where productivity was documented) shows that the most productive one – Borland Quattro failed. As for the second most productive - a project at Motorolla, the team “died” after the company went for a 3rd party product. This comes to show that productivity itself does not guarantee success.

Key factor to success is actually failure. Fast and furious failure plus good retrospectives drives the super performance. Einstein says that one who has never made a mistake has never tried anything new.

At the end of the presentation Jeff talked about well run teams. According to him having a well maintained product backlog, minimized work in progress and the ability to stop when something is wrong are the top factors leading to good Scrum.

2008 Stockholm Scrum Gathering

2008-10-24T14:12:00.003+01:00

Just back from Stockholm and WOW what can I say.. being my first gathering I was impressed with many things. People in the first place. People willing to work together, people ready to form functional teams right from the start. People understanding communication and collaboration. People willing to improve regardless of where they are at the moment. I know gathering "veterans" will have suggestions for improvement but I thought organization and quality of the session was just right and I managed to make tons of notes with ideas, recommendations and contacts as well!

A few good ideas, perhaps initiatives and events also emerged during the evenings even though the price of beer was a bit too high but overall Stockholm is a great place and the stay was enjoyable.

I am certainly going to review my notes, put them in order and publish all the (hopefully) useful ideas for the benefit of the community.

All that when I find enough time between my contributions to transform the way we work!

Team Dysfunctions And Scrum (2)

2008-10-16T15:17:00.003+01:00

ScrumAlliance.org have decided to publish my article on team dysfunctions and scrum here. I really like the edited version as it actually seems more "alive" ;)

NxtGenUG October Event - Southampton

2008-10-06T13:01:00.002+01:00

This month NxtGen in Southampton turns 1 year and to mark the event Rich Allen invited me to do a Scrum talk and game together.

Details about the event are here.

I will report back with more information and maybe pictures ;)

SQL Server Best Practices 1. Big sets, small sets

2008-08-15T12:56:00.000+01:00

SQL Server Best Practices 1. Big sets, small sets

There are two things to remember about sets: the bigger the number of rows we’re working with the slower our query will be and the more columns we return the less efficient transfer of data will be.
I am going to use the Northgale database, for those unfamiliar with it is a script developed by Erland Sommarskog that creates a huge database based on Northwind DB (provided by Microsoft). Just to illustrate the size Northgale has about 6,000 products, 344,000 orders and 2.3 million rows in Order details. I intend to use relatively big sets in order to illustrate better the differences in performance.
Consider the following query:


SELECT *

FROM Products p

INNER JOIN [Order Details] od ON p.ProductId = od.ProductId

INNER JOIN Orders o ON o.OrderID = od.OrderID

INNER JOIN Customers c ON c.CustomerId = o.CustomerId

WHERE Discontinued = 0

AND o.RequiredDate > '05/04/1997'

AND od.Quantity * od.UnitPrice > 100

The returned set from the query above contains about 1.5 million rows and takes about 1 minute and 36 seconds to complete on my machine.

Clearly not fast enough.

The first thing to always remember is that the WHERE clauses are applied at the end. This means that before we apply the where clauses in this example we will always have to use all rows in the tables to perform the joins. For example the first join will join all products with all order details assuming every order detail has product id. Then we’ll have the entire order details table (2.3 million rows) to perform a join with orders and then another one with customers. No wonder the query takes 96 seconds!

So, what can we do about this?

The smaller the number of rows you work with the better. In the example above we should be looking at restricting the set as early as possible.


SELECT *

FROM Products p

INNER JOIN [Order Details] od ON p.ProductId = od.ProductId

AND Discontinued = 0

AND od.Quantity * od.UnitPrice > 100

INNER JOIN Orders o ON o.OrderID = od.OrderID

AND o.RequiredDate > '05/04/1997'

INNER JOIN Customers c ON c.CustomerId = o.CustomerId

What we have done with this one is to move all conditions from the where section to become conditions in the joins. And we’re trying to apply them as early as possible – ie the first time we use the table they apply to.

This reduces the execution time by 30 seconds to 1 minute and 6 seconds.

In Northgale Products table has 10 columns with total size 87 bytes per row. Order adds 200 bytes per row, Order detail 22 and Customer 268. This makes a total of 577 bytes per row. If the query returns 1.5 million rows this gives a massive 825 megabytes return set size. Let’s see what happens if we return only a small number of columns.


SELECT ProductName, CompanyName, AmountPaid = od.Quantity * od.UnitPrice

FROM Products p

INNER JOIN [Order Details] od ON p.ProductId = od.ProductId

AND Discontinued = 0

AND od.Quantity * od.UnitPrice > 100

INNER JOIN Orders o ON o.OrderID = od.OrderID

AND o.RequiredDate > '05/04/1997'

INNER JOIN Customers c ON c.CustomerId = o.CustomerId

This one only takes 20 seconds which represents about 400% improvement compared to our initial query.
As mentioned earlier I have chosen a huge set to illustrate the differences in speed of execution. In reality it is very unlikely that you will need to return 1.5 million rows. It isn’t exactly practical even for one of those large “end of year” bank reports which we used to generate years ago to allow bank officers to waste 20,000 pages to print them. And I am sure that even if you have to select more than a million rows you will most likely need to use paging.
Of course with smaller sets the improvements in performance will be smaller but the changes we made to this query when applied would be valid for any other query even though speed improvements may not be that obvious. If your set is really small the optimizer will notice that and will not use indexes as scanning your small set will be faster.
Hopefully you will find this practice useful and will remember the two advices: restrict sets as early as possible and return only the columns you need.

Optimize me!

2008-08-08T07:52:00.000+01:00

Finally, yesterday I decided to actually read one of the newsletters I get flooded with by SqlServerCentral and then I discovered a really good tsql script to help with identifying slow queries.
The original post is here but as with everything I like I have made a few small changes and would like to post it so I can find it quickly when I need it. Oh, and I might read these newsletters a bit more often from now on ;)

Please note: The code below will only work on Sql Server 2005 or above .


USE master

GO



IF NOT EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[dba_QueryTimeDelta]') AND type in (N'P', N'PC'))

EXEC sys.sp_executesql N'CREATE PROCEDURE [dbo].[dba_QueryTimeDelta] AS SELECT ''this is just temp. please replace with actual code.'''

GO





ALTER PROC [dbo].[dba_QueryTimeDelta]

@DatabaseName nvarchar(255) = ''



AS

/*---------------------------------------------------------------------- 

Purpose: Identify queries that are running slower than normal , when taking into account IO volumes.

------------------------------------------------------------------------ 

Parameters: @DatabaseName, optional



Revision History:

13/01/2008 Ian_Stirk@yahoo.com Initial version

08/08/2008 plamen.balkanski.net Added filtering by Database name



Example Usage:

1. exec YourServerName.master.dbo.dba_QueryTimeDelta

2. exec master.dbo.dba_QueryTimeDelta 'AllItems20080808'



----------------------------------------------------------------------*/



BEGIN



-- Do not lock anything, and do not get held up by any locks. 

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

-- Identify queries running slower than normal. 

SELECT TOP 100 [Runs] = qs.execution_count

            , [Total time] = qs.total_worker_time - qs.last_worker_time

            , [Avg time] = (qs.total_worker_time - qs.last_worker_time) /(qs.execution_count - 1)

            , [Last time] = qs.last_worker_time

            , [Time Deviation] = (qs.last_worker_time - ((qs.total_worker_time - qs.last_worker_time) /(qs.execution_count - 1)))

            , [% Time Deviation] = CASE WHEN qs.last_worker_time = 0 THEN 100 ELSE (qs.last_worker_time - ((qs.total_worker_time - qs.last_worker_time) /(qs.execution_count - 1)))* 100 END /(((qs.total_worker_time - qs.last_worker_time) /(qs.execution_count - 1)))

            , [Last IO] = last_logical_reads + last_logical_writes + last_physical_reads , [Avg IO] = ((total_logical_reads + total_logical_writes + total_physical_reads) - (last_logical_reads + last_logical_writes + last_physical_reads)) / (qs.execution_count - 1)

            , [Individual Query] = SUBSTRING (qt.text,qs.statement_start_offset/2, (CASE WHEN qs.statement_end_offset = -1 THEN LEN(CONVERT(NVARCHAR(MAX), qt.text)) * 2 ELSE qs.statement_end_offset END - qs.statement_start_offset)/2)

            , [Parent Query] = qt.text

            , [DatabaseName] = DB_NAME(qt.dbid)

INTO #SlowQueries

FROM sys.dm_exec_query_stats qs

CROSS APPLY sys.dm_exec_sql_text(qs.plan_handle) qt

WHERE qs.execution_count > 1

    AND DB_NAME(qt.dbid) = CASE WHEN @DatabaseName='' THEN DB_NAME(qt.dbid) ELSE @DatabaseName END

ORDER BY [% Time Deviation] DESC



            -- Calculate the [IO Deviation] and [% IO Deviation]. 

            -- Negative values means we did less I/O than average. 

SELECT TOP 100 [Runs] ,

                [Avg time] ,

                [Last time] ,

                [Time Deviation] ,

                [% Time Deviation] ,

                [Last IO] ,

                [Avg IO] ,

                [IO Deviation] = [Last IO] - [Avg IO] ,

                [% IO Deviation] = CASE WHEN [Avg IO] = 0 THEN 0 ELSE ([Last IO]- [Avg IO]) * 100 / [Avg IO] END ,

                [Individual Query] ,

                [Parent Query] ,

                [DatabaseName]

INTO #SlowQueriesByIO

FROM #SlowQueries

ORDER BY [% Time Deviation] DESC

-- Extract items where [% Time deviation] less [% IO deviation] is 'large' 

-- These queries are slow running, even when we take into account IO deviation. 



SELECT TOP 100 [Runs] ,

        [Avg time] ,

        [Last time] ,

        [Time Deviation] ,

        [% Time Deviation] ,

        [Last IO] ,

        [Avg IO] ,

        [IO Deviation] ,

        [% IO Deviation] ,

        [Impedance] = [% Time Deviation] - [% IO Deviation] ,

        [Individual Query] ,

        [Parent Query] ,

        [DatabaseName]

FROM #SlowQueriesByIO

WHERE [% Time Deviation] - [% IO Deviation] > 20

ORDER BY [Impedance] DESC



-- Tidy up. 

DROP TABLE #SlowQueries

DROP TABLE #SlowQueriesByIO



END



-- Test script

-- EXEC master.dbo.dba_QueryTimeDelta 'AllItems20080808'

Agile Presentations - free or paid?

2008-08-06T13:54:00.000+01:00

I was amazed (if not shocked) to find this website today: http://www.agile-software-development.com
It is selling presentations to help with Agile.

I refuse to accept this.

The Agile community, as is obvious when you look at the search results returned by your favourite search engine, has been trying for years to give these things for free. Here's some evidence:

http://www.mountaingoatsoftware.com/presentations
www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf
http://richardsbraindump.blogspot.com/2007/07/agile-presentations.html

and these are just a few of thousands of examples.

And after all when trying to explain Scrum/XP or agile pracitces like user stories you need to understand it otherwise how do you expect to change others view about the way it is done? And if you do understand it then you will be able to do the presentation yourself!? Even if you struggle for ideas about your presentation simply look for other people's presentation or articles or even books(!) that are available out there. For free. Not for the "price of a light meal" (10 GBP!?)

PS. I promise to find a more positive topic for my next post ;)

Pairing...

2008-08-04T18:39:00.000+01:00

In the software development practice sense:

1.According to a 1975 US Army study of so-called"two-person teams," pairing improves productivity by about 300%.

2.According to a 2000 University of Utah study, pairing reduces initialcode defects by up to 86% at a cost of between 0% and 15% coding time.

Amazing, isn't it? So why self-organizing teams avoid it?
I can see it is right. I know it is right. So what stops me from asking my teams to do it?

Answer: CEO title? ;)

Scrum Gurus Speak

2008-07-16T09:32:00.000+01:00

I am sure not everyone can spend much time reading on scrum development so I thought it might be useful to post this list on here. Will make my life easier also whenever I need to use it ;)

To tolerate a problem is to insist on it. ~ Ron Jeffries

A tool is nothing without a skilled artisan to handle it. ~ Tobias

The practices are not the knowing: they are a path to the knowing. ~Ron Jeffries~

No matter the circumstances you can always improve. You can always start improving with yourself. You can always start improving today. ~Kent Beck~

Anyone who uses the term "resource" when referencing people has to put $1 in the "inappropriate comment" jar! ~ Ken Schwaber

Reality is what we make, not just what we live with. ~Ron Jeffries~

Make it real or else forget about it -- Carlos Santana

Without prioritization, nothing is a priority. ~??

Agility might be said to be about encountering all the problems so early and so often that the effort to fix them is less than the pain of enduring them. ~Ron Jeffries~

"Everything is simple, until you have to do it yourself". ~??

"Once you add people to even the simplest problem, it can get pretty messy in a hurry". ~??

The practices are not the knowing: they are a path to the knowing. ~Ron Jeffries~

Ability to estimate correctly is not an 'ability' ... it is a fluke and lucky guess ~Roy Morien~

A dead scrum master is no good to anyone. ~??

If we're not shipping our software when it's ready, it's poor business practice. If we're not sure whether our software is ready, it's poor software practice. ~Ron Jeffries

Once you start measuring something, you can easily end up in a situation where the measurement itself starts influencing the things you want to measure. – Wolfgang

"A team consists of people under pressure to do their best. Conflict is natural and the team needs to know how to deal with the conflict and have resources to draw on when needed." --Ken Schwaber

Don’t worry about the enterprise rollout today when you have not started even one project. ~??

Team Dysfunctions and Scrum

2008-07-11T23:30:00.000+01:00

I firmly believe and support the idea that Scrum is a management framework and it is not supposed to sort all problems on Earth. I also think I understand well that Scrum was created to solve “a problem” and it duly delivers the goal. This article however is not about how great Scrum is. This article is about a common problem which I believe most if not all Scrum implementations experience. What I am talking about is the problem of overcoming team dysfunctions.
It is known that a Scrum implementation, especially in its early days is expected to and almost always reveals hidden problems and issues that usually cause one or more major team dysfunctions. Finding ways to overcome these dysfunctions is the main goal of this article.
A beautiful beginning
So, you have introduced Scrum and you are working with the first ever Scrum team in your organisation. Luckily all team members seem to be interested and attend all the meetings. You have managed to get a room with whiteboards where the Daily stand-up takes place and you are also able to book an appropriately equipped room for reviews and plannings. Everyone in the organisation seems to be quite excited by the use of index cards and blu-tac which creates an energetic culture and you really feel good about the way things are going.
Retrospectives though feel a bit weird although you can’t quite figure out why. And then suddenly it all kicks-off with an against the rules reaction of a team member during a retrospective meeting after a disastrous review. The team achieved mere 5 points out of 12 planned. Tom, a senior developer says that Chris, a test engineer wouldn’t let the rest of the team do any testing. As a result the team ended up with half of the stories in the final stages of testing just because test engineers would not trust the rest of the team members to provide adequate testing. Surprised by the fact that he is being blamed Chris replies that no one else is qualified to do “proper testing” and anyway testing is not being paid enough attention in Scrum so he believes quality is going down. You finally realise that you need to stop this and you speak about how blaming is not allowed and accent on the positives of identifying a problem which the team now needs to focus on resolving.
The event throws you a little bit out of focus. You see this as a technical issue where testing needs to be automated to reduce the workload of testers. You start reading about test automation and distribute various useful web casts and studies about it. You even change your Scrum training and do it specifically for your test engineers. They seem to understand more and more about cross functional teams and the need of automation. You forget about that retrospective for now.
Although the problem may disappear unfortunately the issue is a lot bigger. Your test engineers do not trust the rest of the team and perhaps vice versa. Lack of trust is usually caused by the unwillingness to be vulnerable. Team members are not open with one another and are afraid to talk about their mistakes and weaknesses. At the same time the fact that your previous retrospectives seemed to be running well suggests that the team might be avoiding conflict. Because of the lack of trust the Team cannot engage in open debates, instead they resort to indirect discussions and shielded comments. Fear of conflict usually only postpones the conflict and once the disappointment reaches certain level the reaction will cause far bigger problem than if the conflict had arisen earlier, or even better resolved in a team debate.
Definitely getting better
Your testers now seemed to have finally got it. At least they no longer question automated testing and seem to be spending time on finding an appropriate tool to use. You still have slight concerns about the way the team reaches quick agreement during planning although you can easily explain this with the team getting more and more used to Scrum. Finally you’re edging close to completing the list of stories in the backlog so you start talking about release. On what seem to certainly be the last planning meeting you start discussing final steps to produce deliverable product which appears to cause a little more discomfort compared to previous meetings. Most unexpectedly Jane, your other test engineer, states out of the blue that she doesn’t care if the team decides that the product is ready for release as she anyway isn’t convinced that enough testing has been done. This sparks Chris’s comment that he wouldn’t accept responsibility for this product as he has never done less testing nor seen a most weird way to develop something. Peter who is a web developer in the team responds that test engineers still do not trust the rest of the team so how can more testing be done when only two team members are testing.
You are disappointed and very concerned that what seemed to be a maturing Scrum team suddenly doesn’t even act as a team. You spend the rest of the day reading about teamwork and various ways to improve it. You are beginning to realise that without sorting out underlying problems it would be difficult to improve practices and productivity.
When a team lacks conflict or what is usually called healthy conflict this could lead to lack of commitment. Because team members cannot air their opinions in an open discussion they rarely if at all commit to decision although they may demonstrate agreement in meetings. Teams members feel as if their opinions do not matter therefore find it difficult to support team decisions. Unfortunately when this is the case it triggers an even bigger problem – avoidance of accountability. Without committing to a well understood plan of action, it doesn’t matter how focused your people are they often fail to call their peers on actions and behaviors that seem counterproductive to the good of the team.
Did you see it coming?
The next morning things seem to become even worse. On the daily scrum Pete, senior developer shows impatience while Chris is talking, interrupts him to make a point about team members not following practices which he believes are a must. Tom also joins in by ignoring the usual order and stating that he feels it became more difficult for him to do “proper” development and increase his expertise. Jane follows to confirm what is obvious to the rest – she doesn’t enjoy working “that way” because she doesn’t see any career progression opportunities with Scrum.
You feel betrayed. It seems like the hundreds of hours spent on convincing people and setting up the basics have disappeared. The team hasn’t been maturing, it hasn’t even formed. Team members were creating artificial harmony by avoiding conflict and now they feel disengaged and demonstrate no commitment.
If the team fails to hold one another accountable this leads to an environment where the most damaging dysfunction is demonstrated. When team members put their individual needs e.g. career development, recognition, etc. or even the needs of a group of people inside the team above the collective goals of the team this leads to Inattention to results.
You are in an awkward situation because you firmly believe Scrum is not the reason for these problems and yet Scrum exposed the dysfunctions. Everyone will be convinced that pre-Scrum no dysfunctions existed and now your team looks like falling apart. How can you change this? How can you resurrect the team and prove to senior management that Scrum is worth the effort?
Can somebody please explain!
I am convinced there is no easy answer to these questions; however I also believe that by following a few simple rules a lot can be done to save a dysfunctional team like the one we just looked at. While a lot of sources suggest that Scrum Masters should not deal with cases like this I tend to disagree. What if middle management doesn’t want to assist? What if they blame Scrum/You for the problem? What if you don’t want to lose the battle?
Before we get onto it I need to warn you that this is not something that can change overnight. You will need a lot of patience, good coaching and facilitation skills and then even more patience. It will probably be many days if not weeks until you see some change and might take up to 6-9 months until you start feeling optimistic about your team.
Are you vulnerable?
It all starts with trust so it is a good idea to look at establishing trust first. Ask yourself these questions: Are you vulnerable? Do you act like you are? Are you communicating enough to make the team aware that you are ready to make yourself vulnerable? Talk to the team or individually. Do a group exercise where you ask everyone to make themselves vulnerable by sharing details they otherwise would not want to. You will find examples easily but something in the lines of: strong and weak side, biggest challenge in school, etc. will do the trick. You also need to find a way to get the team together outside of normal work environment. This may range from organising a night out for the whole team to off-site event. Do as appropriate depending on your budget. Try to do the same activity at least once a month.
How would you now if you succeeded?
- When you start hearing team members answering honestly “I don’t know”
- Team members happily share information and offer help
Plain talking
Politics is when people choose their words and actions based on how they want others to react rather than on what they really think. Politics is when attention is paid to the speaker’s rank rather than dialogue content. Politics kill progress; therefore you need to stop political behaviour immediately.
Is there a lot of whispering in the team? Can your team members freely express what they think without fearing negative reaction? Start by telling your team to think as if they are two levels higher in the hierarchy. Encourage honest comments regardless of how ruthless they may sound. Print out posters explaining why politics is bad and put them on the walls around your team or if allowed in the whole building. Protect and support your people to speak openly with anyone in the company. Encourage healthy debate by asking open questions like: What other options do we have? What would happen if we go with this solution?
How would you know if you succeeded?
- When whispering is gone
- When you can join a team discussion and the topic doesn’t get changed
Something smells bad?
Agreement is good but be careful how you reach it. If you often feel that the team agrees too easily, if decisions are taken too quickly and meetings go too quietly then perhaps not everything is as good as it looks. Such “easy” decisions are bad for the team because team members will not feel fully involved because they could not voice their opinions due to dysfunctions already discussed above.
The only thing you can do in this case is to be there as facilitator and ask the questions required to spark a healthy debate. Ask about any weakness you see or suggest solutions but be careful – try to be only an advisor. When a debate is going in the wrong direction you should try to bring back the business goal and accent on the responsibility and effort required to achieve a great solution. Avoid digging into too much detail – this is where you will usually lose most of your time.
How would you know if you succeeded?
- When team members can say "I may not agree with your ideas but I understand them and can support them."
A group or a team
According to a popular definition a team is a small group of people with complementary skills and abilities who are committed to a common goal and approach for which they hold each other accountable. Presumably if a group of people doesn’t meet these criteria it remains just a group of people.
Do you often notice team members not particularly interested in team decisions? Have you seen team members only interested in their propositions and not willing to discuss or support others’ solutions? Do you often here “This is not my area. You need to speak to X”? Then perhaps you see what I mean. You need to set team goals and make sure everyone in the team is motivated to meet these goals. Sprint targets are good goals to meet but not always enough. Think about some more. These could be one off events like team games or reoccurring like review process. If you do have or want to start a performance review process make sure you go with the review process for agile teams because other process will make things worse. The review process for agile teams however used with well specified team goals might be just what you need to make sure the team is committed to a common goal and meeting these targets is really important for everyone and for the team.
How would you know if you succeeded?
- When sprint targets met rate increases significantly and anyway you will KNOW it on “that” review meeting
I scored two goals!
A friend was telling me a story about his son. The boy used to play football and once when his father (who actually hates football) picked him up after a game he asked: who won the game? The boy answered: I scored two goals. His father took a deep breath and asked again: Who won the game? Then the boy said: we lost 2:7 but I scored two goals isn’t that the important bit?
Clearly team members interested mainly in their individual goals and not paying attention to team’s results are causing the biggest of all damages. Perhaps this is caused by your organisation’s implementation of traditional performance review process, or just because team members fail to see benefits in achieving the team goal, something that is obvious with achieving their personal goal.
Make sure to explicitly set performance objectives and individual goals which are aligned with the team goals. This may seem a difficult task but there is plenty of information how to do it – you may begin by reading about the review process for agile teams. Note that you may need a lot of support from the senior management and it may seem as a difficult battle however only by winning it you can avoid ambiguous goals and the inattention to results behaviour. Team members will still have goals to work towards but now these goals will not get in the way of team’s targets.
How would you now if you succeeded?
- When team members start using more “we” rather than “I”

The show must go on...
The goal I set at the start of this article was to look at a few common scenarios, identify team dysfunctions and suggest ways to resolve them in Scrum environment. I’d like to believe the goal is mostly achieved. Of course this is only a five page article and you will need to read a lot more than this in order to succeed but my feeling is that since the thoughts I share are from experience you may find them useful. And if you do find this article helpful feel free to get in touch but do also remember that the battle to keep your team functional is one that you will have to keep winning over and over again.
Good thing you’re not alone on the way!

References:
The Five Dysfunctions of a Team -http://www.amazon.co.uk/Five-Dysfunctions-Team-Leadership-Fable/dp/0787960756/ref=sr_1_1?ie=UTF8&s=books&qid=1215814459&sr=8-1
Various ideas generated by reading posts on http://groups.yahoo.com/group/scrumdevelopment

The Nokia Test

2008-06-15T15:40:00.000+01:00

About a month ago I have decided to ask everyone in the department to rate our scrum implementation based on questions from the nokia test. I think this was a brilliant idea because it exposed a number of problems with both the teams and the product owners. Also some of the questions were misunderstood by several team members. The summary of results is below:
1. Iteration length less than 6 weeks – 91.67%
2. Fixed iterations – 100%
3. Product Backlog items always estimated – 0%
4. Velocity known– 91.67%
5. Burndown charts generated – 100%
6. Product Owner known – 66.67%
7. No Project Managers interfering – 75%
Interesting that for example on question number one somebody said he isn't quite sure if iterations should be less than 6 weeks and fixed at all! Also somebody has replied with "I don't know what it is" to question number 4(?!). The results of 6 and 7 were just a good reminder to some of our managers to stop messing with scrum.
Overall we had a very positive response following these results so I am thinking about doing it every 6 months ;)

Implementing Scrum

2008-05-30T11:05:00.000+01:00

right, this is not a long and boring article with advices which you don't need. it is just a link to a site which I find quite funny :)

The Product Owner sibject (again)

2008-05-30T11:01:00.000+01:00

A while ago I came up with the 3-headed PO article. Well I must say now time proved it works temporarily only. At least for our teams. What made me thinking about it was this:
http://www.infoq.com/articles/agile-product-owner
which is funny in a way because another article by the same person (who happens to be the guy that gave me my CSM) inspired me to write the 3 headed PO.
I think he is quite right and if you go for a PO subsitute you lose a lot, which is something we (or our teams) realised and we're now making changes to see if we can make things better.

Drop a SQL Server database from your .net code

2008-04-23T15:38:00.000+01:00

Have you ever been in a situation where you need to provide uninstall funcitonality for database installation? Imagine you have just created your nice new database in Sql server and all the scripts have been created but at the last line something happens and you need to rollback. This also includes dropping the database and it isn't straight forward. Closing your connection(s) doesn't help as they don't close straight away. While looking for a solution I came accross one and decided to share it here.
This is the method I created:

private string GetKillProcessStatement(string database)
{
string result = string.Empty;
StringBuilder sql = new StringBuilder();

sql.AppendLine("DECLARE @SQL varchar(max)");
sql.AppendLine("SELECT @SQL = COALESCE(@SQL,'') + 'Kill ' + Convert(varchar, SPId) + ';'");
sql.AppendLine("FROM MASTER..SysProcesses");
sql.AppendLine("WHERE DBId = DB_ID('" + database + "') AND SPId <> @@SPId");
sql.AppendLine("SELECT @SQL");

SqlConnection dropDbSqlConn = new SqlConnection(_masterConnStr);
dropDbSqlConn.Open();

using (SqlCommand sqcomm = new SqlCommand())
{
sqcomm.Connection = dropDbSqlConn;

sqcomm.CommandType = CommandType.Text;
sqcomm.CommandText = sql.ToString();

sqcomm.Prepare();

object obj = sqcomm.ExecuteScalar();

if (obj!=null)
result = obj.ToString();
}
dropDbSqlConn.Close();
return result;
}
A few clarifications: _masterConnStr is the connection string to the master db on this server. If you need to create a db you will probably already have this one available. In this case it is a private member in the installer class. I explicitly need it to be inline sql as i don't want to install stored procs in other databases on the server. Database access rights to do that will be available because the user we require also needs to create dbs.
The inline sql when executed returns a list of kill statements like this one: 'Kill 11;Kill 23;Kill 45;' . The numbers will be the process ids in Sql Server. Once you get this you are just a simple ExecuteNonQuery of this string before you will be able to drop your database regardless of the number of connections on it. Ok I know there might be more arguments for connection initiated between your kill execute and your drop statement execute but there is cure for this as well. If this is a worry then execute this sql script before you issue the drop statement:
"ALTER DATABASE [" + database + "] SET SINGLE_USER WITH ROLLBACK IMMEDIATE";
I wouldn't be bothered to do so as in my case this is a newly installed db and there is no chance someone will know about it.
Back to the point I believe this is a good solution to ensure that you can drop a sql server db and the statement won’t fail because of open connections.