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.
User Story Sizing and Acceptance Criteria
By · CommentsWhen doing sizing with story points people will get hung up on the details. They want all of the acceptance test requirements understood. The beauty of story points is that they have no units of time associated with them. We are just look at relative complexity compare to other stories in our back log. So if each story is at the same level of understanding it all works out.
It is not necessary to do detailed acceptance criteria before sizing. The acceptance criteria should be very general. Such as what is the expected result and what are critical negative cases. We do not need to deal with the wireframes or UI at this time. This will be done during the iteration planning. Here is an example from the a team backlog:
Confirm – Email – Indicate email not listed
As an agent, I want the system to provide an option, so that I can indicate that the email that the customer wants to confirm is not listed.
Acceptance:
Expected: Agent enters an email that has not been previously used and the system indicates the email can be confirmed.
Negative: Agent enters a email that is in the system and the system indicates the email cannot be confirmed for the customer.
Team Work
By · CommentsAgile relies on self organized teams. But most of us do not really understand what it means to work on such a team. The model I see most often is that the ScrumMaster or the Technical Lead will take control of the team.
I have seen one team where the ScrumMaster actually created all of the tasks for a sprint and assigned members of the team to work on these tasks. In other cases the technical lead controlled what tasks are created and made sure the team know who are working on the tasks.
I know that each team members may have special skills and it makes sense that they are the best choice but in doing this we loose the value of the team. A team functions best when we share knowledge with each other. It is great when you have a team in which members will help each other even if they are not the expert in the field. Also, a team protects itself when the knowledge is distributed among the team.
As team members we should be willing to learn new technologies. Also, team is more efficient because there is no “down” time.
When a team creates the tasks they are going to do in a sprint they assume ownership of those tasks. They have created the tasks and will be more likely to see that they get finished.
Demotivating a team
By · CommentsAgile methodologies support best software practices. One of these practices is that working together as a team is more productive then individual contributors to a project. But it is easy for a team to be demotivated.
We all start out being motivated. We like the work we do and we want to do a good job. So what happens? It is the situation we work in that demotivates. This includes the stress and company culture. This quote is from “Agile Coaching”:
These are factors that demotivate people if they are not present, even though these factors are not motivators when they are present. For instance, fast computers, decent coffee and fair pay won’t be noticed if they are there, but their absence can demotivate employees.
It important to be aware of what may be demotivating a team.
Introducing Agile Change
By · CommentsChange is difficult for all of us. We get comfortable in a routine and like to maintain it. This is especially true at work where we spend a majority of our waking hours.
It becomes a challenge to Agile practices to an organization or a team because of resistance to change. Here are some ideas on how to introduce change :
- Sell the team on the problem that needs to be fixed
Many times we need to convince the team there is a problem. It is important we explain what the problem is and have the team agree that the problem needs to be addressed. - Have the team read about Agile
Introduce the team to reading materials that clearly explain the Agile concepts you want to introduce. These may include blogs, white paper and books. - Attend Agile user group meeting
There are Agile user groups in any metropolitan area. It is good to attend these meeting to get other developers opinion about Agile. - Do not be fanatical about Agile
When you are passionate about Agile methodologies it is easy to be fanatical. This will turn people off because you do not listen to their concerns. - Choose one Agile practice to introduce
To much change at one time overwhelms a team. Introduce one new Agile practice a month. This will make change easier because the team will have time to learn about the practice and apply it.
Personal Agility – Your development practices
By · CommentsWe often look at Agile adoption from an organization level but what about adoption at a personal level> What does it mean for you as a developer to adopt Agile methodologies.
Let’s start with your own developement practices. What do you value as a developer? How have you improved your development practices over the last year?
Here are some practices that an Agile developer should adopt:
- Test Driven Development.
This is more then just writing unit test, it is having the unit test drive your development. - Code refactoring
Do you leave the code you work on more readable and easier to understand? - Code ownership
Do you take responsibility for what you do?
I am sure you can add to the list. The point is are you constantly trying to improve the way you develop software.
Cool Under Pressure – Learn To Adjust
By · CommentsIt is a given that no project goes as planned. We all get into situations where we want to panic. Many times we see this when adopting Agile methodologies. A practice we put in place seems to back fire. The developers are actually less efficient. What do you do, there is a dead line to meet?
It is times like these that you must keep your cool. Carefully evaluate the situations. Take a step back and look at what may be causing the problem. Experts know that plans are not executed as hoped. They will readjust on the fly but still keep the goal in focus.
The beauty of Scrum is at the end of every sprint you can do a retrospective. This gives you a mechanism to adjust in mid-project.
XP eight hour burn
By · CommentsWe have been told that when developing using Agile we should get into a rhythm as a team. We should be working just 8 hour days. Now to many this seems absurd. No developer can get by just working 8 hours a day, what would my manager think?
I read the following from the book The Passionate Programmer:
If you have 70 hours available [in a week] each hour is less precious to you than when you have forty hours available.
Here is another quote:
Bob Martin’s eight-hour burn places a constraint on you and gives you a strategy for dealing with that constraint. You get to work and think, I’ve only got eight hours! Go, go, go! With strict barriers on start and end times, you naturally start to organize your time more effectively. You might start with a set of tasks that need to get done for the day, and you lay them out in prioritized order and start nailing them one at a time.
Activities fill all available time.
Take on this challenge, this next week plan on working just 40 hours and make each one of those hours count.