Archive for General
Team Work
Posted 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
Posted 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.
Personal Agility – Your development practices
Posted 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
Posted 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.
Being Passionate
Posted by: | CommentsHow often do we go about our jobs and have not real passion about what we do? When an friends asks what you do for a living what do you tell them? Do you say I work for company XYZ or I am a C/C++ programmers (or what ever you current skill is)?
Is there a skill you can teach others because you really believe they would benefit from learning the skill? Do others recognize an underlying passion to make your work place better or the world better around you?
So much about agile is about be passionate first about improving your own skills and the improving the skills of those you work with. Be passionate about improving!
There is much to change
Posted by: | CommentsThis morning I had a very interesting discussion about the culture at the company I work for. We as developers have been instructed to use a testing tool that our QA group uses. This is all well and good because the tool is based on JUnit and is XML driven. The problem is that the tool is only supported in the QA testing environments. The tools cannot be used in the regular development environment. So if developers do use the tool for tests it will have to be for QA regression testing and cannot be used in a test driven development (TDD) style.
This is very frustrating because TDD is the proven way to create quality software. Also, developers are going to resist using tools that do not enhance their job and the quality of their software. Who wants to add more time to an already tight schedule to develop test that one cannot use.
I was informed that our culture does not value testing by the developers. Oh, there have been directives that all new code will be unit tested but because good tools have not been provided this type of testing is spotty at best.
To do our job efficiently and produce top quality code we need to have environments that support us not hinder us.
Micromanaged
Posted by: | CommentsIt is interesting to see how resource managers like to micromanage the task list. It seems that when a task list is defined for a story that it is etched in stone. Let’s face it, none of us can plan ahead 24 hours let alone for a two week sprint. We have a general idea and a goal we are striving toward. The tasks give a road map to get there, but there may be many detours along the way.
The Team
Posted by: | CommentsI have been learning much about introducing Agile methodologies into a large organization. Many times it has seem almost hopeless. But I took a different approach over the last several months. I decided to really make the team I am working with the most productive team in our company.
Well we have gone through two major product releases and the team is really coming together. They have learned to work together and leverage each other strengths.
One thing I am learning it to look for the little changes in Agile adoption. Over the months these little changes accumulate and make for some very significant changes in an organization.
Self organizing as a team
Posted by: | CommentsHave we paralyzed our workers so they do not have any initiative? I recently started forming a new team and ran into several issues. We defined a product backlog and tasks to be done in this sprint. When the planning was finished the tasks that an engineer thought he was going to work on were removed from the sprint. Mind you there is enough work to do in this sprint to keep the team busy. This engineer though he had nothing to do because his tasks were removed. Then the resource manager was upset because they had put the member on the team and they had nothing to do.
This is prime example of the individual not thinking as a team member. This individual must realize they are a member of a team whose goal is to produce a successful product. We need to adjust to the needs of the team.
What are you reading today?
Posted by: | CommentsI have alway stressed continuous learning. The constant comment from people who know me is how large my library is. I guess I got this from my father who was constantly purchasing and reading books. Because technical books are outdated so quickly I constantly removing old books from the library. A couple of years ago I joined http://my.safaribooksonline.com/ . This has been a great resource for technical and business books realated to technology. I am no longer filling by books shelves. It helps having a tablet pc because it make reading online more natural.
Today I ran accross an excellent book, 97 Things Every Software Architect Should Know, 1st Edition. I highly recommend this book. It is easy reading but one of those books filled with axioms that we need to reminded of all of the time.
The first maxim is “Don’t Put Your Resume Ahead of the Requirements”. How often do we want to use a new technology because it will look good on our resume?
There are 96 more to go. You may disagree with what these experts are saying but they are thought provoking. Take a look at this book.