Edge of Chaos | Agile Development Blog

Do you know how to run a really productive meeting? I don’t. I’m learning, and I run meetings with various success so far. My most recent insight is related to the size of a meeting group. Let’s evaluate various sizes and identify strong and weak sides.

Presentation

If you have hundreds of people all you can do as a single group is to listen. You have one presenter that broadcasts information, all the other people consume the information and digest it inside. On the picture below presenter is marked with  red color as a sign that he is the most (and the only) active person there. There is a huge diversity in this group, but there is no feedback, so decision making is impossible. All you can do is listen, think of some new ideas and write them down to discuss later.

Large Meeting

Ten or more people sitting at a single table make a large meeting. Again, there is a great diversity among people, but… Usually several people are almost completely silent, they just listen and do not give anything back. There are several very active people that lead the discussion mainly. The real problem with such a large group is that nobody can consume information from more than 1 person simultaneously. It means when somebody talks, all the others should shut up and listen. Often a large group splits into smaller groups randomly and neighbors discuss something  ignoring the rest of the group. I believe this happens when people ‘feel’ the need for a better communication format. Overall, it is very hard to have any meaningful decision in the end and very often the result of such a meeting is … Yes! To schedule another meeting!

Small Meeting

This is the real problem solver. 3-4 people communicating intensively have more chances to really get the problem and nail the decision. Communication is very dense and there are many feedback loops. You say something, I catch new ideas and say them back. Broadcast-consume-broadcast cycle repeats many times. All people are active. Everybody feels the pace and there is no place for boredom.

Duo Meeting

This is not a meeting, but rather just a discussion. This type of communication happens all the time in pair programming, for example. Communication is very rich and dense, however, sometimes there is a lack of diversity. That is why pair sometimes brings a third person into their discussion to solve a doubtful problem. 3 people can solve problems more effectively than 2 people.

Solo Talk

If you talk alone, probably it is better to visit a doctor. It is much more efficient to have an “inner dialog” than thinking aloud. Surprisingly, thinking is a quite good method to solve problems. For example, I like to think alone. However, sometimes you get stuck and see no fresh ideas coming to mind. Moreover, solutions that you invented may be really bad (or not as good as you think). Group discussion is still the best way to evaluate ideas and select the best.

Now let’s have a look at the resulting chart. It shows meetings by 2 axis: intensiveness of communication and groups diversity.

I think it is better to run meetings with 3-4 people to solve problems effectively and split large groups into many small groups. A small group has enough diversity and intensive collaboration to be effective. Several small groups have even greater diversity and potentially can create an even better solution than a single small group. Sure, it will be more expensive and slow process if you invite many people. Just consider several possible options for your next meeting.

I got this insight on lean and agile techniques in military context when reading  “Ideas Made to Stick” book.  The workflow of the military was described there as an example of how important it is to make messages as concise as possible to accomplish tasks.

The evolution of the military strategy with dates and sources is not a subject of this blog :)
With no extra details, here’s the core of the point I’m trying to make:

First the Army’s approach was to make sure that every single action is planned down to smallest details. But, as they found out, “enemy bears no plans”. An unexpected move could destroy the whole set-up so  “all king’s horses and all king’s men” could not make the Army function again. Effectively, I mean.

So, they reverted to something very similar to agile technique of creating user stories – Commander’s Intent. Commander’s Intent is “the commander’s stated vision which defines the purpose of an operation, the end state with respect to the relationship among the force, the enemy and the terrain; it must enable subordinates to quickly grasp the successful end state and their part in achieving it”.

Do you see the resemblance? It’s a replica of lean production principles, only in military, not in civic, context. And it’s exactly like the agile principle of engaging people and encouraging their creativity to achieve one common goal.

I will not go into quoting sources on the web on Commanders’ Intent and military doctrines to find more analogies and similarities in military setup and lean/agile methodology.  I just outlined the idea.

There’s a misconception related to this topic: Some people think that agile works all OK for lazy folks. It’s all about freedom, about looseness, no obligations. Not at all. Agile is less conventional, it does not care about being in the office at 9 am sharp, or about wearing a tight business suit. But agile projects do have their Commanders’ Intent and they require genuine responsibility and engagement from the team – the soldiers.

Now, as  the Army follows agile principles, would you need any better proof on the effectiveness of agile and lean methodology?

Bringing together agile philosophy and software development outsourcing has been one of the hottest topics over the last decade.  Lots of blog posts, discussions in social networks — people try to figure out for themselves if it’s at all possible to align agile methodology with the existing reality of outsourced projects.

How can vendors who practice agile gain new customers? How can customers as newly-converted adepts paste their vision of agile thinking on their existing outsourcing partners?

First of all, let’s look back into when and why actually did it all start with IT outsourcing. Manufacturing outsourcing existed since long ago, but IT offshoring only started at the end of 80′s – beginning of 90′s. Companies jumped at the opportunity to save bucks and use cheap labor not only for producing goods, but for producing software. So, the main point is that from the very beginning outsourcing has all been about saving money. No other notable motivation – just saving money and using cheaper labor.

Next, along comes agile manifesto. People start seeing that the waterfall approach  they’ve been using with their outsourcing vendors is not that good after all.  Fixed price contracts do not guarantee real value (Scott Ambler writes very well on that in this article). Next, the more labor is outsourced to some country, the higher are the costs, so the main point for outsourcing which is cost savings makes no sense any more.

There’re other even deeper-lying consequences. On the one hand, the country which outsources – or businesses in this country not the country itself – they save bucks but lose in the long run as they do not grow their own engineering minds, let alone all the problems that you have working with remote teams – yes, we have all this telecom in place, but nothing ever will replace face-to-face communication. If you often go on business trips to the outsourced destination to talk to your team – again, it’s more costs.  On the other hand, outsourcing makes a dangerous long-term impact on the recipient economies as well.

But the point is not about how bad or good outsourcing is.  Vendors have written an array of blog posts on how to align agile and outsourcing – and that’s natural – they want to keep going, so they do everything to back up their point of view proving that agile goes well with outsourcing. This might work true in some cases.

The companies that outsource on the other hand – they have legacy outsourcing teams. They need to get going with them as well, to stand up to all the funds already invested in their outsourcing center/provider.

So with all this outsourcing in our hands – what do we do?

As an agile outsourcing vendor, you should be ready to invest lots of time and effort to educating your new customers on the value of agile and to building a solid relationship. This might be a very difficult task since some people just don’t want to get educated and prefer to stick to good old fixed price bids, logging and billing for gazillion of change requests, lack of communication and other “joys” of classical outsourced development.

As a company with established outsourcing facility, you’re better off. But perhaps you could be even better off if you started this relationship not with an overseas company, but with a guy next door at least.

Anyway,  you are where you are – so you would need to work with your outsourcing partner to practice the agile approach, since at the end of it all work with agile methodology brings real value, as opposed to counting short-term waterfall pennies and losing long-term gain.

I think unclear specifications is #1 source of bugs. If you deliver something that was not intended, there will be many complaints from customers. In customer’s opinion almost all these complaints are bugs. Also, without instant communication it is very easy to miss important details and release an un-polished user story with a number of small glitches.

Agile development is very rapid. In many cases the path from idea to user story in progress is extremely short, it may be even 1 day. With this hard pressure on,  it is very easy to make errors in user story description. Product Owner may miss some important details and as a result the story will do something wrong, something that was not expected.

This is the first question you must ask… is it a bug, or is it a change? I’ve seen a lot of bugs that have come up that were “We asked you for x, never thinking about y, so could you please change the system so that y is covered?” It’s a business scenario, so there’s no reason to expect a developer or tester to anticipate/test it. I know where we’ve struggled is in injecting items into the product backlog, we tend to classify it as a bug and so we end up with a lot of bugs, but not a lot of change in the back log. That’s exactly what I think we’re supposed to be avoiding in Scrum or any other agile methodology. As we see change, we should be taking it on as a feature and prioritizing it accordingly. Only when it’s something broken should it be called a bug.— Jim Leonardo

The best solution to this problem is communication.

Clarification meeting

The important thing in software development is to put everyone on the same page. Developer, Tester and Product Owner should run a small meeting about user story, thus forming a mini-team. If a user story has several developers and several testers, all should participate.

The goals of the meeting are:

• Ensure that everyone understands what should be implemented.
• Brainstorm acceptance tests/test cases and create a check list.
• Reveal and eliminate all discrepancies in story description/specification.

We have these meetings at TargetProcess and they are very efficient and helpful. Recently there have been some stories  with no meetings, and as a result the stories had more defects and a longer cycle time. Side effect of the meeting is that Product Owner receives less questions about functionality later, thus having less interruptions (which is good).

Stories should be ready before iteration start

It is a good idea to have all user stories described with good details before iteration start. Thus testers and developers will have time to review them and prepare questions to the iteration meeting. It may trigger a much better discussion and reveal some interesting problems that were unclear initially.

There is a danger to document more user stories than required, and it will be a form of a waste. Product Owner should maintain good balance here.