Sit with the team
By · CommentsTeams are core to agile practices and a ScrumMaster plays a critical role in optimizing team execution. One of the common impediments that interfers with this is the team work area or lack thereof. Without a common workarea it is very difficult to really understand what is going on with a team. The daily standups are a very inadequate way of tracking team progress. So much more is learned when you hear the intra-team discussions. It is these informal times expose what is really going one with a team.
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.
One for the team
By · CommentsAs a ScrumMaster I am really sold on the Agile methodology. My enthusiasm can create angst for the team. I am really proud of the team I am working with right now. They have overcome many obstacles and really embrace Agile. They do not have a “cargo cult” mindset but a real commitment to be the most productive team in the company.
The team is willing to be a leader and will take on the risks. Because of this can do mentality I wanted to have all who were interested to view our first sprint demo. So what I did was use the largest distribution list for our department for our invitation list. Well this was a mistake and really caused the team to become very uneasy. They pointed out that we had overcome many obstacles in this sprint but there was not really much to show for it in the demo. We have completed one user story well and it is “done” according to our new standards of acceptance but it was only one user story.
They were correct. Perception is everything and we only have a “simple” user story to display for all of our work the last 3 weeks. The extended stake holders would not really understand what was involved in what we accomplished.
So I canceled the original meeting and invited a much smaller group to stake holders to the sprint demo. A lesson learned on consulting the team before make a major decision on who to invite to our sprint review.
The Team and Company Culture - Part 2
By · CommentsTeams are powerful entities. They are much more powerful then just a group of individuals. This in itself can be a major deterrent in changing the culture. Once a team is formed, stays together for six or more months and becomes self-organizing it can become very influential.
It is very difficult for managers to ignore the requests of the team especially when it is very productive and working toward the corporate goals. It is interesting that teams usually request changes that will make them more productive. These changes such as a team work area, change in performance review procedures, setting goals and self-governance are actually better for the company.
But all of this runs contrary to most companies management hierarchy. How does one manage a self-organized work team? You don’t! Good teams need to be guided to where they should be going. The manager needs to make sure they do not go off track and provide the best environment for the team to excel. This leadership is very important for a team to function at optimal levels.
The Team and Company Culture - Part 1
By · CommentsDoes a company really believe that is team is more productive than individual contributors? Take a look at the how a company does performance reviews and compensation.
Most performance reviews focus on how the individual performed in the last year. After the review the individual is informed as to what their new compensation with be. Very little is considered about the team they are working on. The following are some of the issues this causes for a team:
- The individual’s performance is more important than the team’s performance.
- Individuals feel reluctant to share their knowledge with the team.
- The team is not rewarded for performing well.
In most companies the culture is based on the individual not the team. So the individual is concerned that they will not receive the appropriate recognition if contributing to the success of a team.
Team Building and Focus
By · CommentsWhen there is a lack of focus this is a lack of teamwork. When each developer has other projects to work on they are not working together.
In an Agile team it is critical that each member has the same vision and goal. Unless the team is first the team will not succeed. When team members are more concerned about their own individual gaols instead of team goals you have lost the team focus.
Unless we can all capture the same vision we will fail. Oh, we may get a product out the door but will it be the best product we could have produced if we were focus.
In order to produce quality team work and capture the vision we have to spend quantity time together. This means working side by side with each other for hours a day. Time spent together ends up creating a team works together well an helps keep them focused on the vision.
Team Focus or Lack of it
By · CommentsDuring a sprint a team has to remain focused on the goal. So often the team gets distracted from the goal. Some of the sources of distraction are as follows:
- Other Projects
- Personal issues
- Lack of hardware
- Lack of team synergy
Other Projects
These can range from pet project from a manager to the previous project a team member was working on. Also, there always seems to be an emergency project that needs to be worked on. All of these affect the velocity of a team and may affect if the team is able to finish the user stories it has committed to. It is important that the ScrumMaster communicates to the management and product owner how much other projects are affecting the team and when they become major impediments. I my role as a ScrumMaster this has been the most prevalent issues I had to deal with. It is no fun when you have to tell a resource manager you report to that they are affecting the viability of a project.
Personal Problems
All of us face time when we have family issues or have physical problems that need attention. Unfortunately our jobs may be the cause of many of our problems. Our jobs cause stress that may affect our health and our families. It is important that we create a healthy work environment that does not cause excessive stress. Employees need to have time with their families and time for recreation to keep a healthy body. A good exercise routine leads to a more productive employee and less visit to the doctor. If we keep to a 40 hour work week we will have time to spend with our families.
Lack of hardware
It in uncalled for that companies invest in adequate hardware for their employees. Niceties such as dual large monitor, powerful laptops and large disk drives are cheep compared the cost of a employee. Necessary hardware should be available to the employee without having to go through excessive red tape. Also the supporting build and testing environments should be setup and supported from the beginning. There is no excuse for the lack of good hardware.
Lack of team synergy
So often a team is a team in name only. So often the individuals are just working on their tasks and nothing else. If they finish early they will find something that interests them to do and not even consider what other task they can work on.
In a productive team the members learn how to leverage each others strengths. They work together for a single purpose. There is no individual recognition. We as a team work together toward the goal of finishing the sprint goals. Each member makes sure they do their part by taking on available tasks.
Definition of Done - How to ensure quality in a product
By · CommentsAgile requires a change in our mindset in regards to quality. We all have given lip service to quality but are we really ready to make a commitment to quality. As usual Agile concepts are simple but hard to implement.
Quality starts first of all with the backlog. The customer’s highest priority user story is what is developed first. A quality product must first meet the customer’s expectation of what is important.
We will make the assumption that we have chosen the top priority user stories for a sprint. How do we decide when we have finished the user story and it is ready to presented to the “world”.
There are three major areas of acceptance:
1. Code quality
2. Functionality
3. Presentation (usability)
1. Code quality
a) Is the design reasonable?
b) Is the user story testable?
c) Is the code well written?
d) Have we followed a consistent data model?
e) Are we following the best practices?
2. Functionality
a) Is the code unit tested?
b) Is the test data available?
c) Have we worked on creating test fixtures?
d) Does it meet the data requirements?
e) Does it meet the logic requirements?
f) Have we automated our testing?
3. Presentation (usability)
a) Is the layout correct?
b) Are all of the UI assets in place?
c) Are all of the interaction components working properly?
d) Is the data displayed correctly?
e) Are the screens being displayed in the correct order?
f) Is there valid wording all text fields?
Who is responsible for “signing” off on these acceptance criteria:
1. Product Owner
2. Quality assurance developer
3. User interface designer
4. The team
We all work together as a team to build the unit tests, automation tests and making sure the presentation in correct. The product owner creates high level acceptance tests. The quality assurance developer assures the story in testable and creates the function test tasks. The software engineers work with the QA developers when creating the unit tests and automation tests. All during the process the team is working together to make sure the user story is acceptable at all levels.
We should not wait until the end of the sprint to have the quality assurance developers begin their testing. Once a section of code has been develop the QA developer should be consulted to make sure software engineers are meeting the requirements. Once a UI component is finished the user interface designer should be consulted to make sure it meets the requirements.
When all of these acceptance criteria are meet the story is done. It is very important the team does not over commit to the number of user stories that can be completed in the sprint.
The goal is a quality product that we are proud of and an our customers are very pleased with.
Multi-tasking verse Single-task (part 2)
By · CommentsWhy do managers believe that they are getting more productivity from a person if they are working on multiple projects? I know they are afraid of have “down” time. But what really happens when a person has some down time?
Let me give you an analogy. Let’s say you by a new delivery van (yes we need to help the economy right now) and you want to start using it in your business. Now you want to make the most of this asset. So you decide that you will drive it at 100 miles hour and that you will not take it into the shop for routine maintenance because you will not be able to make deliveries with it. How long would your new new delivery van last? Is this the best use of your new asset?
Developers cannot be constantly running at peak speeds. Eventually they will wear out. Also, they need to be able to work on skill improvement and have a chance to expand their horizons. Slack time in the schedule is important just for the sake of sanity.
Having a developer working on multiple projects is bound to wear them out. This can be displayed in lack of enthusiasm, increase sick days or just plain bad attitude.
Multi-tasking verses Single-tasking
By · CommentsCompanies seem to want to increase productivity of their workers by making sure they are fully utilized by putting developers on multiple projects and forcing them to multi-task. Manager fear “down” time for their directs. But is it wise to schedule 100% of an employee’s time?
What are the perceived benefits of multitasking:
- A developer will always have a task to work on.
- More projects can be staffed.
- More development hours are recorded against projects.
But are benefits producing a good return on investment? Let’s look at each one of these benefits.
1. A developer will always have a task to work on
Every time one changes tasks especially on another project there is a problem of context switching. First one must take the task they are working on and save the information that is needed to work on it in the future. When starting a new task, previous information about the new task must be gathered and the task started. This may create considerable overhead with large tasks in different projects.
Also, a developer may choose tasks that are “easier” to do and avoid project critical tasks when making a switch. This makes them look more productive because tasks are getting done.
2. More projects can be staffed
It does look like company resources are be used more efficiently because more hours can be allocated. But are these really productive hours?
3. More development hours are recorded against projects.
We can all look busy but are we really productive.
One of the foundations of Scrum is that the team is able to focus on a project for a sprint. This quote is from Scaling Lean and Agile Development page 142:
Do your job. Focus all your efforts and skills on doing the work that you’ve committed to doing. Don’t worry about anything else. In Scrum, work is not arbitrarily forced on people, and work cannot be added during the iteration. Nor is there any multitasking or distraction, because each team is 100 percent committed to the set of small achievable items chosen for the short iteration. There is no partial allocation on different projects; partial allocation means partial results. Each person’s time is 100 percent allocated to the goals of the iteration for the product. This provides the foundation for the focus and reduction in multitasking that leads to quick delivery and productivity
When a team can focus on a single goal they will be more productive. Assigning team members to multiple projects is a sure way of decreasing productivity.
Enterprise Transition Community
By · CommentsWe have a book club at work. The book under discussion right now is Succeeding with Agile: Software Development Using Scrum by Mike Cohn. If you have not read this book it is a must read. I bought copies for my team (I did get reimbursed later) because I thought it was so good. The following are comments about ideas presented in this book.
Agile so many times starts at the developer level. Usually a team lead or manager has read about Agile and wants to use it with their team. That is the way I started, I was a team leader. This works great for a limited period of time util you run into the bureaucracy of the standard software development process. That is the time to start thinking of how to transition the whole company or division.
One concept introduced by Mike is the Enterprise Transition Community (p. 63).
The Enterprise Transition Community exists to create a culture and environment where change can be released by those who are passionate about the success of the organization and where success leads to more passion from more people. The ETC does this not by imposing changes on the organization but by guiding groups who are implementing changes, by removing obstacles to doing Scrum well, and by creating energy and excitement for the change.
In other words you need a team at the appropriate level in management to take up the Agile cause. They are the ones who will guide the agile adoption and remove the obstacles. Read this section in the book, it might help you in your adoption.