Categories
Recommended books
  • The Book of Awesome: Snow Days, Bakery Air, Finding Money in Your Pocket, and Other Simple, Brilliant Things
    The Book of Awesome: Snow Days, Bakery Air, Finding Money in Your Pocket, and Other Simple, Brilliant Things
    by Neil Pasricha
  • Succeeding with Agile: Software Development Using Scrum
    Succeeding with Agile: Software Development Using Scrum
    by Mike Cohn
  • Six Thinking Hats
    Six Thinking Hats
    by Edward de Bono
  • Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition (Addison-Wesley Signature Series (Cohn))
    Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition (Addison-Wesley Signature Series (Cohn))
    by Lyssa Adkins
  • Pomodoro Technique Illustrated: Can You Focus - Really Focus - for 25 Minutes? (Pragmatic Life)
    Pomodoro Technique Illustrated: Can You Focus - Really Focus - for 25 Minutes? (Pragmatic Life)
    by Staffan Noteberg
  • Man's Search for Meaning
    Man's Search for Meaning
    by Viktor E. Frankl
  • Eat That Frog!: 21 Great Ways to Stop Procrastinating and Get More Done in Less Time
    Eat That Frog!: 21 Great Ways to Stop Procrastinating and Get More Done in Less Time
    by Brian Tracy
  • The Abilene Paradox and Other Meditations on Management
    The Abilene Paradox and Other Meditations on Management
    by Jerry B. Harvey
  • The 7 Habits of Highly Effective People
    The 7 Habits of Highly Effective People
    by Stephen R. Covey
  • Rework
    Rework
    by Jason Fried, David Heinemeier Hansson
  • Born to Run
    Born to Run
    by Christopher Mcdougall
  • The Big Book Of NLP Techniques: 200+ Patterns & Strategies of Neuro Linguistic Programming
    The Big Book Of NLP Techniques: 200+ Patterns & Strategies of Neuro Linguistic Programming
    by Shlomo Vaknin
  • Agile Coaching
    Agile Coaching
    by Rachel Davies, Liz Sedley
  • Behind Closed Doors: Secrets of Great Management (Pragmatic Programmers)
    Behind Closed Doors: Secrets of Great Management (Pragmatic Programmers)
    by Johanna Rothman, Esther Derby
Powered by Squarespace

Monday
Mar282011

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.

Tuesday
Jan252011

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.

Friday
Jan142011

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.

Monday
Jan032011

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.
Thursday
Dec302010

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.