Archive for Agile
A time for reflection
Posted by: | CommentsAdopting agile practices in an organization can really be frustrating. Our general resistance to change seems to be at the core issue.
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:
- Individuals and interactions over processes and tools
- Working product over comprehensive documentation
- Customer collaboration over contract negotiation
- 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.
In the flow
Posted by: | CommentsI was reading an article by Michael Swaine on multitasking. What really caught my attention was this quote:
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.
Command and Control
Posted by: | CommentsI have just started reading Collaboration Explained: Facilitation Skills for Software Project Leadersby Jean Tabaka. Over the next several posts I will basing my comments on material I have read from this this book.
As you know, I am very interested in what is involved in creating a high performing team. Why do we not see more high performing teams in corporate America? I believe that the “command and control” management philosophy contributes to this.
Now if you ask most ScrumMasters if they use command and control and they will say no they do not. But is this really the case when they are working with teams?
Here are questions you should ask yourself about you interaction with the team:
- Are all decisions involving the team made by the team?
- Does the team feel they control their destiny?
- What are the factors that prevent the team from being empowered?
Review you own style of facilitating. Then ask the team to evaluate you style of facilitating. As with all Agile processes this constant inspection helps us to improve how we interact with the team.
Team vs Team
Posted by: | CommentsI have been thinking about teams and teamwork. Every company I have worked for will say that they have teams of developers working on a project. But what type of team are they working on?
Growing up I participated in teams sports. As I reflect on my high school years there were two types of teams I played on. I participated on both a track team and a football team. Let’s look at these teams.
Track Team
On a track team each team member has their own specialty and tried to excel at it. We as individuals tried to finish high in our event so that we could get points for the team. The team that had the most points in the end won the meet. When I ran the two mile run it was up to my performance in how I finished. During training I would get suggestions from others on technique but individual performance was key to creating team success. No real collaboration was need when we participated in the meet. The only place you saw collaboration was in the relay races.
Football team
I also played football in high school. This is a team sport where collaboration was critical. We had a play book to memorize. Each team member had to know their position on the team and usually several other positions in the event someone got hurt. We huddled together, heard the play and then we executed. Practice during the week focused on the execution of the plays in order to prepare for our game on Friday night. We worked on perfecting our “product” so it we could have a good “demonstration” for our “customers”.
In my experience most teams in a large organization are like a track team. The teams are made up of highly skilled developers with very little collaboration between the developers.
A Scrum team is more like a football team. We have a play book we must execute against. Our understanding of the play book and our role on the team is important for success. Also, being able to learn other roles and assist where ever needed is important for a team.
What type of team are you on?
Change – It Starts With One
Posted by: | CommentsI just finished an excellent book on change:
It Starts with One: Changing Individuals Changes Organizations
This book does an very good job explaining how to move an organization through change. As with Agile the principles in this book are simple but difficult to implement. Here are the three principles of implementing change in an organization:
- See”…we must understand that people will not change if they fail to see the need and they often fail to see the need for change because they are blinded by the light of what they already see—the powerful mental maps that have worked well for them in the past.”Our own successes are often the reason we do not see the need for change.
- Move”First, even after we have helped people see that the old right thing is now wrong, and we have painted a picture of the new right thing, that new map must have a clear destination or vision.”People need a clear vision for change. But change always involves personal risk. These risks must be mitigated so as a person moves through a time of incompetence they know that their will be rewards along the journey.
- FinishSo many times change is not successful because people get tired or lost.Change is hard and it is so easy to go back to doing what you comfortable doing and are competent in doing. During this time of change constant feedback and encouragement are needed.Also it is easy to get lost when making the change. Often people wonder are they making a difference or are they performing the correct tasks.
This books gives excellent examples and tools to use to help implement change in an organization. As Agile coaches we are often in the middle of change in an organization. I know from personal experience it is helpful to have additional insights on how to manage change.
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.
Culture: Competence verses Team
Posted by: | CommentsFor most of my carreer I have worked in organizations with a competence culture. This is a culture that relies on very good developers who do their job well as an individual. The individual is recognized for their contribution to the organization. I have to admit I have performed well in a competence culture. During my tenure at Texas Instruments I obtained the position of ”Member, Group Technical Staff”. This is Texas Instrument’s first level of recognition of key technical leaders.
The competence culture seems to have served most of the companies I work in well. So what are the downsides of such a culture. Here are some of my observations over the years.
- Knowledge hoarding
Knowledge is the key in the competence culture. The more you know and understand the greater the recognition. You do not have time to mentor others because you want to make sure your corner on knowledge is protected. - Individual politiics
It is who you know and can impress. Now no one would admit this directly but we act it out. We make sure we get invited to the right meetings and talk with the right people. - Lack of code ownership
As we move about the company we leave our current projects to work on new better projects. No one really owns the code. It is left for others to fix the bugs. How do you track down who can work on a bug when no one owns the code? Take a look at some legacy code. How did the code become such a mess? Was any one really proud of the code? - Lack of continuity
No one really understands the legacy code because the individuals are gone who worked on it. There is no shared domain knowledge.
How does this differ in a culture built around teams. Here some of my observations:
- The team is the priority
The idividual becomes a contributor on a team that is greater the sum of it individuals. We work first and formost for the team. Other commitments take a lower priority in the company. - The team grows individuals
In participating on the team we become better and more well rounded developers. The individuals share their knowledge with each other. We work on helping each other to enchance their skills. - The team respects individuals
All of us have important contributions to make to the team. The most junior developer is considered a very important member of the team. We listen to and respect all voices. All of us have blind spots and it takes others on the team to protect us from ourselves. - The team become the repository of knowledge
We as a team take responsibility for the software we are working on. We as a team own the code we work on. If a defect is found in our code we will fix it. It is the teams code not an individual’s code. So if an individual leaves a team others in the company know who to turn to when a defect is found in our code. - The team become the champion of quality
We set our standard of quality. We want our team to be recognized for producing quality products. We know our reputation as a team depends on this and we cannot hide by moving on. We are really proud of our code.
This ideal culture built around teams takes years to build. You cannot be reforming teams every 6 months and expect to create a culture based on teams. Teams need to be in place for years. Sure the members of the team may change but the team itself will live on.
In order to have long lived teams it is best to have 7 members on the team. This way even if two team members move on at the same time you still have enough core team members to move forward and train new team members.
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”.
Team Formation
Posted by: | CommentsI have been helping a new team form over the last 2 months. As the ScrumMaster I have been really interested to see the team become a high performing team. Team dynamics are really hard to understand especially in a new team. Here are some principles I believe are really important to help the team become a performing team.
All Teams Go Through the Storming Phase
Why do team members try to fool themselves that they do not need to go through a storming phase? I see this in many teams with which I have worked with. They will tell you that they get along and they have passed the storming phase. I know it is not so. We have not experienced “Fierce Conversions“, conversations that are courages, authentic an clear. We definitely need these during the storming phase. And without them we will never really get out of the storming phase.
Confidentiality
It is so important that what is discussed in the team and how we come to our decision is held in strictest confidence. Because I have worked with teams in multiple environments at work and outside of work I learn to live by this principle. But that is not so in a new team that is going through the storming phase. During this phase difficult issues are faced and not all team members agree with the team decision but will abide with the decision to see if can work. Team members must not express their displeasure to management for a decision that team has made. Team players keep it within the team.
As a coach I have challenges ahead of me to help the team. They are great people and make a great team. Helping them requires that I understand my own style of coaching better that I can lead them to understand these principles.
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.