Some approaches are as follows:

1. Do a big design up front and design the architecture that everyone has to follow
   Well BDUF do not withstand the test of time. We know any architecture will be modified as soon as we start programming.
2. Have an architecture review board
   This ends up being a bottle neck in the process. These architects are not really doing the coding so they do not always understand the issues that are being faced.
3. Do nothing and let the teams be
   Well this is tempting and just let the architecture emerge from each team. But you lose consistency really fast. Also, the individual components do not work together well.
4. Use the Scrum of Scrums meeting
   This is a meeting that focuses mainly on inter-team impediments. We have to remember to keep our meeting focused on their agenda and not to try to do to much in one meeting.

So I propose that a formal community of practice is the answer to this problem. We must recognize that teams left to their own will approach architecture is different ways. This is of real concern on a large project with multiple Scrum teams.

What is this community of practice and what do we expect of it?

1. A weekly meeting with one developer from each team
   This has to be an regularly scheduled meeting. It can range in length from 1 to 2 hours. I recommend that the developers be rotated who represent the team and  make this a monthly rotation to keep consistency.
2. Each team  presents the code they have developed during the last week
   This is a high level review of the code. At this time the architecture of the code is reviewed.
   1. Does the code follow best practices?
      There should be automated tools to help enforce best practices. So the question here may be one of accountability.
   2. Does the code enhance the overall design of the system?
   3. Is there duplicated code between the teams?
   4. Where can the code be more efficient?
3. Each team is responsible for refactoring their code
   The changes will be agreed to by the community and implemented. With this continuous inspection the architecture can be refined and adhered to.

One of the guiding principle of Agile is continuous inspection. The community of practice is a necessary meeting when working with multiple teams. It will scale in a similar matter as a Scrum of Scrums.

We have now decided that we need to write user stories. The begs the questions as to who our users are. When I first started thinking about our users I originally came up with three or four users. I believe this is very typical when people start with user stories. They pick the obvious users and then create their stories around them. In doing this we miss many requirements.

I decided to do some brainstorming using a mind map. With this mind map I wanted to explore the users of our product. What you see below is 15 minutes of one person doing the mind map (me).

Our Users

Wow there are many more than 4 users. I am sure there are more users if more of us were working on the mind map. (I actually thought of several other users since I did this map.)  When you start evaluating these users you realize that there are many requirements that can be derived from each user. Of course you may see roles that an user enacts that be combined with other other roles to streamline the number of users.

My premise is that every requirement can be derived from a specific user role. Even the technical requirements have a user.

So as you start creating user stories,  brainstorm as to who all of your users are. When you do this you will be able to derive a rich set of user stories that will cover the majority of your requirements. If you find a missing requirement it is my premise that a specific user role was missed.

Here we go. My Texas college has been playing American football for years. We are a small school and this game has been very expensive to maintain. After the latest soccer world cup we decide we want to switch over to soccer. Now this is not being received very well by our alumni. After all this college is in Texas and football is supreme. Our alumni are major contributors to the college so we cannot offend them even though it is cost us precious dollars and resources to maintain the football program.

So here is the great idea that the athletic department has come up with. Instead of doing a complete switch from football to soccer let’s move to soccer without breaking the rule and  try to please our alumni.

1. We will use our football pads in soccer
   We made such an investment in pads for the players we cannot do away with these. Do not mind that it slows down the players on the soccer field it has been proven that pads will protect the player.
2. The new soccer team will wear the old football uniforms
   We cannot waste what we already spent on uniforms. We know they may get in the way of moving the ball down the field.
3. The soccer team will huddle every time they want to move down the field
   Huddles were very productive in football so they should work just as well in soccer. They allow us to determine what strategy we should take in moving toward the goal.
4. We will form a scrimmage line before each play
   We have to know where the player are and were they will be after we start the play. We can call the play and be able to execute it.

In the above scenario we have not broken any of the rules for soccer. We have just adopted our previous experience in football to soccer. Tell me what success do you think this new soccer team will have? To switch to a new game you need to be committed to making a complete change.

Both football and soccer have very similar objectives, you move the ball down the field and get it across the goal. They use the same playing field and both have players that move the ball toward the goal. But how they do this is very different.

When switching for a waterfall to a Agile methodology you cannot have it both ways. Practices have to change in order for there to be success in the Agile process. Each have a very similar goals but a very different approach. Do not try to “blend” the approaches.

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.

1. A team member as an individual
   Team members are not just resources to be used to create a product for the company. Each of them has goals and passions. Helping the individual to realize his or her goals and taping into their passion make for a much more resilient individual. When the team member is doing something they really want to do and are passionate about they will overcome the obstacle they encounter.
2. The team encourages each other
   Every team member has insecurities and areas they feel they are insufficient in. When these are manifested in a team the other members find way to encourage the other member through mentoring or helping them through difficult tasks. The goal is to have well rounded team members who excel at what they do.
3. The team is protected from outside intruders
   There are intrusions on the team from management, product sponsors, other teams and other projects. Management has expectations and many time the teams method of meeting those expectations does not match the way management expects a project to be done. In this scenario it is important to over communicate with management. Have them understand that the team is progressing toward the goals management has set. This is difficult for a ScrumMaster steeped in Agile technology. We many times have to provide more documentation then we feel is necessary.

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.

As an Agile practitioner I can see the benefits of adopting the agile practices. I must always remember that these practices are really the best practices for doing good product development. A case in point is that the Scrum agile framework can be adopted to any industry that has to deliver products to its customers. How you implement the details of product development in the framework should just reflect the best practices for your profession.

I would make a slight change to the Agile manifesto:

1. Individuals and interactions over processes and tools
2. Working product over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

Any product that is under development can benefit from the Agile manifesto.

Any business that values the individual worker will thrive. An organization that creates an environment where the workers are creative and enthusiastic will go a long way to producing great products. Remember you employees are not a interchangeable resource but creative individual who are responsible for making you successful.

Having a tangible prototype in the customer hands early help manage the expectations and requirements given to the team. An unpolished quickly released product that demonstrates the core functionality early goes an long way in creating confidence in the working relationship between the customer and the product development team.

You guarantee a successful product when your customer is involved during all phases of product development. We always run into obstacles and challenges when developing a product. Having the customer involved will help us understand what requirements are critical and how we can manage the requirements that cannot be meet.

We are in an ever changing world. While developing a product we must expect change. Unless we can create and release a solution instantly, there is going to be change. We must embrace change and learn how to best manage it.

It is always good to reflect on the basics. Sometimes we get so caught up in the day to day challenges that we forget the why of what we are doing.

People

It starts with the person. It does us good to contemplate how important each individual is on a team. You do not have a team without people, how trite but all so true. When you start treating the members of a team as resources in a company you have removed their humanity. A team members first of all wants to be respected for who they are. They are a complete person with dreams, goals, likes, dislikes,  families, and a job. We a leaders must value each individual for who they are. Rarely does an team member purposefully not be productive. If we do have a situation like that we need to understand where that individual is in their personal life and where they need help. I cannot emphasize enough the value of the individual first.

Passion

When you are passionate about a task nothing will stop you. It is amazing how many obstacles are overcome when we have a goal that we are going to meet no matter what happens. We have all had experience where we worked on a project that we really enjoyed. It was hard to keep our minds off the project. Passion comes from really believing in yourself and the vision of the project you are working on.

In a class Mike Cohn commented on he did not want his team members working on open source projects. He wanted them so passionate about their work that they had no desire to work on any software outside of their job.

I know many of us downplay emotion on the job. But what would happen to our work place if everyone was passionate about their job?

Productivity

Getting the job done and doing it well what we all want. As we build up the individual and guide that team we will see amazing productivity. I am always perplexed when managers interfere with the composition  of a team and do not expect any changes in productivity.

When you have a closely knit team, any change in the makeup will have a very negative affect on  productivity. The worse case scenario is when a team member is removed from the team without any team input. This is like losing a family member.  It will take the team time to adjust.

Free your mind to focus on a single activity and you can achieve flow.

Flow, being in the zone, whatever you call it, should be your mind’s goal. When you’re in that state, you’re totally focused and performing at your peak. Like Pete Townshend’s Pinball Wizard you “ain’t got no distractions, can’t hear those buzzers and bells.” You become one with the game.

So it’s not just daydreaming and limerick writing. It’s gaming. And that means it’s coding, too, because coding, when you’re in the zone, can absolutely be like playing a video game.

Many of us as developers have experienced times when we were in the flow. We were so concentrated on the task that we our productivity was amazing.

What would happen if the team was in the flow? I have seen this happen in the past and it has been amazing to watch. It like watch a professional basketball team in the NBA finals. Each player knows their role and for 60 minutes they are absolutely in tune with each other.

Now I realize that it is impossible to be in the flow all of the time but we should try to limit distractions as much as possible. This flow gets interrupted by the random meetings on our schedule that seem to be a must. Team members have remarked that just when they really get into the flow they have to go to a meeting. It would be nice to time box these meetings so that they occur during set times during the day.

We as a team have decided that we are going create a timebox to get into the flow. We are going to reserve the mornings in our next sprint for development tasks as a team and limit other meeting to the afternoon.