Archive for General
Planning
Posted by: | CommentsI really appreciate that amount of time we spend in planning for a sprint. For a two week sprint we spend one day in planning. I know in the past that teams that I worked with thought this to be a “waste” of time. They wanted to start programming. My new team is developing a habit of doing sprint planning which will be very beneficial.
We are tasking our user stories with a high level of detail. Most tasks are not more then 4 hours in length. This is helping the team to better understand what needs to be done. During the planning session yesterday we moved some user stories to the backlog because the product owner was not clear on the requirements. In the past this would have lead to development churn or wasted time during the sprint. It is much better to discover this at the beginning of a sprint through sprint planning.
Planning for the two week sprint also helps the team to understand inter-dependencies. Having smaller sprints gives the freedom to move stories to the backlog.
Starting all over
Posted by: | CommentsWe are starting all over again. This is a time of new beginnings. I have joined a new team and this time I am not the Scrummaster. This is a switch for me. I believe this will be a good role for the next 6 months. It will help me understand the technical challenges being faced by team members.
This team I am on is very new. I reminds me of 3 years ago when I first joined my current employer. Here is how they are new:
- New to the company. Most have only worked for the company 3 or less months.
- New to the process. Most have not worked with agile before.
- New to each other. Most did not know each other 3 months ago.
So this team must go through the forming, storming, norming and performing stages. It seems that every time I work with a new team that they think they are different and do not have to go through these phases. Now matter what they think they will progress through each of these stages.
Another observation is that the team is not good at planning for a two week sprint. They are overly optimistic and have committed to more work then they can get done. I know they are new and want to prove themselves but they do set themselves up for failure.
Pre-Planning or Sprint 0
Posted by: | CommentsAdopting Agile in an large organization presents many challenges. This is especially true when a project contains multiple teams that have to create an unified product. One must be able to parse a project so that individual teams can work on a sub-system and have it integrate smoothly with the product.
In the organization I work with we have added a new step in the process. I will call this our Sprint 0 iteration. This iteration is used to create the initial backlog for the release. The participants in the meeting involved the team working doing the programming, the lead architect, best practices team, product owner, service representatives, user interface designs, quality assurance and management.
The goals are as follows:
- Understand any major architectural issues
- Identify where the software has to interface with external subsystems
- Define how to communicate with external systems
- Define the overall system constraints
- Have the product owner clarify the requirements
- Define the initial user stories.
- Size the user stories
Even though I believe very much in team making its own design choices, having the experts available to assist the team is very beneficial. This allows us to better understand what we are developing. This has given us a level of confidence in our estimations for the upcoming sprints.
This does not minify the role of the product owner during a sprint. Their involvement is very critical to the team maintaining their velocity during a sprint. The product owner has to constantly reviewing the working software to make sure we are on track with the expectations.
Software Delivery – Continuous Itegration, Build and Deploy
Posted by: | CommentsYears ago I worked for a start-up company and under a very demanding manager. He was a stickler about not having build breaks and that our software could be delivered to whom ever we want after a build. The first task he would do on a new project was to create the make file that would build the install script for the product. To him that was the most critical component and must be constantly maintained during the development cycle. After every build of the product we had an install package.
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?
- 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. - 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. - 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. - 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.
Safety of the Team (part 2)
Posted by: | CommentsI have been reading about the different meetings an Agile team has over the course of a project. I have come to realize that these meetings when done well offer a sense of safety for a team. Well thought out and facilitated meetings help the team move toward being a high performing team that provides safety to its members.
- 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“ - 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. - 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.
Book review: The Dip
Posted by: | CommentsThe Dip: A Little Book That Teaches You When to Quit (and When to Stick) by Seth Godin
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.
- 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. - 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. - 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. - 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.
Problems With a Release Plan
Posted by: | CommentsI work for a Fortune 500 company and we are implementing Scum. Within the Scrum framework you are to do a release plan. When working for a start-up company this was very straight forward because only one team was working on a product line and we could create a credible release plan. But in a large organization release planning for a team is much more complex. We have a product that has multiple teams and multiple product owners. At this time our release planning is not working. We have not had a successful release plan. Here are some of the reason I believe this is true:
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.
Are You Reading?
Posted by: | CommentsI believe that a college education’s purpose is to train you for a lifetime of learning. I myself have a liberal arts degree in biology and chemistry. My present occupation has little to do with my degree but my education helped to train me to learn.
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”.
Who Makes a Good ScrumMaster
Posted by: | CommentsWe have created 7 new Scrum team as we transition toward Agile in our business unit. Each of these teams has been assigned a ScrumMaster. Each of the ScrumMaster has been given some training. The teams have started using the techniques of Scrum such as a planning session, daily Scrum meeting, sprint demo and 3 week iterations. Some teams have started doing retrospective. But are we actually realizing the full benefits of Scrum?
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:
- 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? - 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. - 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. - 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. - 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. - 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.
How a Team Thrives
Posted by: | CommentsIt is really exciting to see team meet their potential. This is one of the most gratifying experiences I have had as a ScrumMaster. What did make the team such a success? Here are some observations:
- 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.