Agile Lean Europe Network

As an Agile enthusiast I'm always prepared to support and promote good Agile initiatives. A few weeks ago I got involved in Agile Lean Europe Network, which is a group on LinkedIn that aims to improve the collaboration between Agile fans in Europe. It was initiated by Jurgen Appelo who is trying to move the countries in Europe a little closer together. You can read more about his great idea on his blog.

First pan-European Agile gathering will be organised at XP2011 conference in Madrid. But, before the gathering each country should self-organize and prepare their statement of what they want from Europe. All agilists from Europe are invited to join local Agile communities in your country to prepare for the ALE gathering in Madrid. You can find more information about emerging local communities here.

In Slovenia we have already started a discussion about this topic on our local LinkedIn group Skram.si.

See you all at XP2011.

How To Use A Constellation To Jell A Team?

When you start new project you assemble a group of people to work on this project...this is the easy part of the job. The really hard part is to transform this group of people into an effective team that run like a well-oiled machine and that will successfully finish the project. And here is where most of the managers fail.

 

It takes time for a team to jell because it takes time for team members to get to know each other and build trust. And this is a prerequisite for effective communication which is imperative for the project success. That's why you must create many opportunities for team members to get to know each other better. And one such opportunity is a Constellation exercise?

 

The main purpose of this exercise is that the team members learn more about one another, see what other team members will do and not do, what they do and do not believe, and what they will and will not tolerate. It is especially useful at the beginning of a project when most team members do not know each other.

 

How to facilitate a constellation exercise?

 

Choose any object (chair, ball,...) and put it on the floor in the middle of the room. This object represents the center of the constellation and all team members should arrange themselves around this object. Tell them that you are going to read some statements, and as you read the statement they should gravitate toward or away from the center object in relation to how true the statement is for them. The more true the statement is for them, the closer to the center they should move.

After you read the statement everyone should move at the same time and they should not pay attention where other team members are moving. After everyone has moved they should all look around and see where other team members stand and they should feel the shape of the constellation. Once they have looked around, read the next statement.

After you read your statements, let the team members write their own statements. Collect all the statements and read it to the team.

 

Here are some statements that can be used:

• I like to work alone
• I am competitive
• I like to facilitate meetings
• I am a perfectionist
• I like to learn new things
• I like surprises
• I like lots of documentation

To learn more about the exercises that can help the team jell read a great book Coaching agile teams written by Lyssa Adkins.

The 3 A's of awesome

If you are looking for something inspirational you should watch Neil Pasricha's great talk about awesome things in your life. I also recommend you to check his blog which won Webby Awards in 2009 for Best Blog or read his bestseller book.

Agile Principle 2: Changing Requirements

This is the second post in the series of 12 posts about Agile Manifesto Principles. They are the foundation of all agile methodologies and every Scrum team member should be familiar with them.

 

Here is the second principle, that talks about change:

 

Welcome changing requirements, even late in 

development. Agile processes harness change for 

the customer's competitive advantage.

  

In software development we all strive for a projects where customer would never change their minds. And we all know that will never happen because changes are inevitable in real world. Customers usually do not see a problem of changing requirements as a serious one.

 

Traditional development process prefers sticking to their well-thought-out plans that are the result of the requirement-gathering phase. Introducing change late in the development process is costly because you need to repeat the whole waterfall process (analyse, design,...) for each change.

 

Agile methods take a different approach and treat change as an expected and welcome part of every project. After all, it is all about satisfying the customer because it is necessary to preserve customer's competitive advantage.

During the project the customer can continue to make changes, as long as they prioritize these changes in the appropriate iteration. Product owner is responsible for understanding of the customer needs and grooming the product backlog (prioritizing work based on business value) even near the end of the project. It is even better to make decisions later in the process when we have a better understanding of the product that we are building. Because a product backlog is a living thing that evolve constantly it can respond to the actions of customer's competitors. Agility is all about flexibility and being open to change is a big advantage.

 

You need to remember the following two words about this principle: welcome (changing requirements) and harness (change)!

 

You can find the explanation of the first principle here.

Scrum & Agile Manifesto Principle 1

Many software development companies are striving to become more agile and the Scrum is the agile buzzword #1 at the moment. The problem is that some companies or teams want to adopt Scrum just because they read about it on the internet and they are sure that if it is a simple agile framework it must be very easy using it. Besides, who wouldn't want to be more agile in these days?

Some people start using Scrum although they know almost nothing about the Scrum. It makes me really sad when I meet people with the following mindset "Scrum == Sprint". Yes, all they know about Scrum is that you have to work in some iterations called "Sprint". And at the end of the project they are so disappointed because the project was not as successful as they expected. That is because the Scrum is dramatically different from traditional sequential development. 

 

Every Scrum team member must be familiar with the basic values of Scrum. That's why I decided to wrote 12 posts about the foundation of all agile methodologies including Scrum: Agile Manifesto Principles. In every post I try to will explain one principle in a very simple way.

 

Here is the first principle:

 

Our highest priority is to satisfy the customer

through early and continuous delivery

of valuable software.

 

At the start of the new project you have to answer one really big question, what exactly are we building? The short answer is, that you must build the software that is going to be of value to the customer and will satisfy their needs. But in the reality it is not so simple to achieve that.

 

In the sequential development project you would first start with a lengthy up-front requirement-gathering phase. The result of this phase would be hundreds of pages of detailed requirements documentation where all features are equal important. Let's face it, the customer don't care about documents and UML diagrams and it is hard to get the right information from the customer and put it on the paper. They just want to get the software that maximizes the added value to their business and they don't know exactly what that value is on the first day of the project. There is a big chance that there will be some disappointment on the customer side when the software will be presented for the first time at the end of the project, although the software works as at it is described it the documentation.

 

There is a total different story with Scrum teams which adapt early and continuous delivery of valuable software because the client is involved throughout the lifetime of the project. That is how you can get early customer feedback and valuable emergent requirements. Scrum team documents all the features in a product backlog, which is a master list of all desired functionality not yet in the product. Product backlog is also known as prioritized feature list and priority is assigned based on the items of most value to the business or that offer the earliest ROI and value. Product owner has to groom the product backlog continuously because items are added, removed and reprioritized each sprint as more is learned about the product being developed. The result is that the most important and highest-priority items are implemented first because they are found at the top of the product backlog.

 

So, remember two words about this principle: satisfy (the customer) and valuable (software)!

 

You can find a very brief explanation of agility here.