Software delivery is so critical especially with very complex projects that involve multiple teams. Deploying software into a SOA that is 24×7 presents challenges that we never faced in our small start-up. But the principle remains the same, “You need to know how to deliver your product right from the beginning of the project”.

How many project put this as a top priority? I have seen many situations where how we  deliver  product into the “live” environment is not considered until the end of the project. Why should this be important?

1. Large systems can be fragile
   With a small product you can control the environment it will be deployed into. With large system deploys their are many factors you have to be aware of during a deploy. Just one table not being updated in a database can cause serious problems during a deploy. With the multiple connections that are involved it can be very difficult to track down the problem.
2. The individual teams cannot understand the whole
   It is unrealistic to have all of the teams on the project understand every aspect of the deployment. The team’s focus is on their functionality they need to provide.
3. A continuous integration,  build and deploy process needs to be implemented
   Continuous integration, build and deploy are the cornerstone on which a solid software system can be built. Without this in place you will have difficulty deploying a workable solution.
4. A integration and build team is critical
   This is the team that is responsible for building and deploying the product. They understand all of the components of the system and determines the deployment strategy.

A good Agile process depends on having the foundation in place. Continuous integration, build and deploy is the foundation for good process.

1. The team chartering meeting
   Any time a team is formed or there are major changes on a team you need a rechartering meeting. This meeting helps define the goals, rules and social order of the team. The members of a team start trusting each other because as a team they are making rules they will operate under. The initial interactions take place in this meeting. You have a chance to learn about the personalities of the individuals. Also, this is a time for you in encourage team members to share their past technical skills and personal goals. This collaborative even will help team members realize that they are not “alone” but have others who are willing to work with them and help them to overcome any obstacle. As the common saying goes “There is safety in numbers“
2. Planning meeting
   Most people have their work planned for them and they just do their job. Actually being able to plan the short term schedule can be intimidating because you are going to be held accountable for it. But being able to plan as a team helps eliminate the unknowns. There are many voices involved in doing the planning and thus the risks are mitigated. Each team members  has a perspective that needs to be heard. As we learn to trust each persons input the team because a haven for creating a plan that is workable and can be believed in. The team members have sense of safety in that they know a plan is doable.
3. Retrospective meeting
   This meeting is so critical. This is when we can celebrate our successes and correct our short falls. No one really likes to face up to their mistakes on a regular basis. This meeting allows the team to look at ways that they can improve. As we identify more with the team we become comfortable in making the personal improvements in order to help the team. We have the support and encouragement of other team members to help us grow professionally.

Have you ever wondered if you were just in a dead end job or the present project was not going anywhere. I am sure we have all wondered this.

Now you wonder what this has to do with Agile coaching. I believe there are time when we need to know when to quit trying to get an organization to try to adopt Agile. But knowing when we are just going through the Dip verses facing an impossible situation is the key.

The emphasis of the book is to be the best in your world. Those who are best reap the rewards for their focus and labor. This little book is full of wisdom on what questions you should ask yourself.

1. Is my persistence going to pay off in the long run?
   Some organizations are only to go so far in adopting Agile. Learning when to quit coaching an organization can save much turmoil and wasted effort.
2. When should I quit? I need to decide now, not when I’m in the middle of it, and not when part of me is begging to quit.
   I have heard it said that before you start any endeavor you should have an exit strategy. You should plan on what you are willing to endure and sacrifices you are willing to make for the sake of project. That way you will not quit just because you have had a bad day.
3. What chance does this project have to be the best in the world?
   Read the book and get a better insight on this question. We all should be striving to be the best in our world.
4. If it scares you, it might be a good thing to try.
   How is that for advice! How often do we let fear impede our progress.

I recommend you get a copy of The Dip. It is a short book but well worth the time spent reading it.

1. The product owners are not empowered
The product owners do not really have control over the product. There are other stake holders that really are driving the product. Therefore the product owners are always reacting and are not able to set a true product road-map.

2. There is not one Product owner for the overall product
This person would handle the priorities for the product as a whole. Our product owners need direction and coordination from the lead product owner. This would help protect the individual product owners from all of the stake holders that are seeking to set priorities.

3. There is no vision for the product
There has to be an overall vision for the product. Why are we doing this product, what are our goals, etc.? This vision must be clear and concise. This vision is what we look to when the product owners set their priorities in the backlog and when there are conflicting priorities.

4. There is no vision for the periodic releases
Each release must have its own vision. What is the reachable goal for this release? How do we coordinate our teams to meet this release goal.

Without these basic fundamentals in place it is going to very hard for the product owners to create a credible release plan.

Reading good authors is an inexpensive way to do self training. People are always amazed at how many books I own. A good friend of mine asked me how many linear feet of books shelves I have. I never considered that question before and the estimate I came up with is 250 linear feet of shelf space. Needless to say I am an avid reader.

This amount of shelf space has caused some friction with my wife. So now days I do not buy physical books if I do not have to. If I buy a book I try to get the Kindle version or the mobi version. I have readers for both. I read them on my TabletPC which is a slate form factor and on my iPod touch. It sure beats adding more book shelves and pleases my wife.

I have a subscription to safaribookonline. This is really a great technical resource. There are thousands of technical books available for you to browse or read. What is really great is the Rough Cuts section. This allows you to read books published by Addison-Wesley before they are released. In the last six months I have read all of the new Mike Cohn Signature books weeks or months before they were published.

I have listed some of my top books for Agile practitioners in the side bar of my blog. Please take a look at these books. I will be adding more books in the future.

As I always say “Leaders are readers and readers are leaders”.

The ScrumMaster plays a pivotal role in helping the team adopt the spirit of Agile. They need to bring the team to an understanding of why certain practices are important. I know for many years as I lead ScrumTeam I have failed in getting the team to understand why we use certain practices.

Here are some qualities of a good ScrumMaster:

1. Be a listner.
   They need to really understand the team. How are the team members relating to each other? Are they really working together? Do they respect each other?
2. Be a Team Coach
   They take responsibility for the team’s adoption of Scrum. It is important to monitor the teams progress toward adopting the practices of Scrum.
3. Be a Team Member Coach
   The team is made up of individuals. The ScrumMaster takes interest in each individual so that they can achieve their maximum potential. Each individual will accept the tenants of Scrum in varying degrees. We need to know where the individual is in their own adoption of Agile.
4. Be Humble
   They are not doing this so we can enhance our personal resume and show everyone what we have done. We take pride in what the team is doing. It is what the team has accomplished that makes a difference. The ScrumMasters roll is that of a servant-leader.
5. Be Passionate About Agile
   A good ScrumMaster really believes in what they are doing. They have an enthusiasm for Agile. They have been trained and are continuously doing self training in Agile. They want to do the best job they can.
6. Leave it to the Team
   A good ScrumMaster does not make decisions for the team but lets the team make their decisions about the process. The ScrumMaster will train and guide the team but will not make decisions for the team.

There are other traits that are good but the ones I have listed I consider to be critical. Unfortunately I have not witnessed these qualities in most ScrumMaster I work with.

• The team was co-located in a large office. Our desks were around the perimeter of a very large and spacious room. This allowed for us to communicate freely.
• We were “isolated”. The team was located 200 miles from the corperate head quarters. The team was self organizing and knew what their objectives were.
• We could move fast. We were working for a startup company. There was less bureaucracy to have to deal with.
• We respected each other as team members. We had been laid off together froma previous employer and knew each other well.
• We were not afraid to try new ideas. Our team tried new technologies with impunity.
• There was no fear of failure. We were confident in our own skills and the company wanted us to try new ideas.

These factors help us to be a very productive team. We were always presenting new and exciting features with everyone of our sprints.

These are all critical factors in forming the team that is high performing.

• Do you ever think of a member of the team as a problem that has to be fixed or do you really try to understand his or her reason for their behavior?
• Do you spend time learning about a team member’s hopes and aspirations?
• Do you know the names of their significant others?
• Are you really concerned with their professional and personal growth?

I know this may seem necessary because we are technical professional like dealing with one and zeros and not with the soft sciences. But as a leader it is important you really know the members on you team not about them. But I must warn you that you must be sincere in this venture. You must check you own attitudes about team members and make sure you are really concerned about them.

These are all critical question when adopting Agile. The role of a product owner is unique to Agile. It is the combination of multiple roles.

An excellent new book is being published on the role of the product owner:

Agile Product Management with Scrum: Creating Products that Customers Love (Addison-Wesley Signature Series) (Paperback)

I have been reading the electronic version of this book and found it to be very informative. The chapter headings are:

1. Understanding the Product Owner Role
2. Envisioning the Product
3. Working with the Product Backlog
4. Planning the Release
5. Collaborating in the Sprint Meetings
6. Transitioning into the Product Owner Role

Roman Pichler, the author, does an excellent job of presenting the material. This book is another excellent addition to the Mike Cohn series.

The book will be available the middle of April.

We as ScrumMaster need to keep in continuous touch with the team. It is imperative that we sit with our teams as much as possible. This is the only effective way you can be an effective gate keeper.