Archive for General
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.
Agile and Yearly Budgets
Posted by: | CommentsI just got done reading material on annual budgeting process in large companies. When we think about this yearly ritual you start realizing how counterproductive it can be.
We always joked about Internet time in the last years of the 20th century. Companies were accelerating the deployment of products and ideas in months instead of years. One could not imagine trying to forecast a budget for a year.
Now we are in uncertain times. Yearly budgeting just restrains us because we allocate funds for projects we assume are going to be valid 6 or 9 months from now. Can you really predict what is going to happen 6 months from now for any company?
Companies need to make all processes agile to truly be Agile. That includes the area of budgeting.
Estimating work to be done
Posted by: | CommentsOne of the most important task for an Agile team to have good estimates for development tasks. This will get better after working together for several months. We as a team get into a rhythm that allows us to best under each team member’s strengths. This is one of the reasons a team must stay together for a long period of time.
As a team we must be honest about our estimates and take the following in to account. There are three common reasons why a story may not be estimable:
Developers lack domain knowledge.
Developers lack technical knowledge.
The story is too big.
Working together as a team
Posted by: | CommentsEvery team members contributes. It is vital the the team cultivate ideas from every member. Each of us has a unique perspective that helps make the team succeed. Working together a community helps each of us to better understand our unique skills.
This entails that we are willing to learn from others on the team There is no place for a prima donna on a team. The member fresh out of college has knowledge that a 30 year veteran does not have. It takes humility to learn from the junior member.
Also we much be willing to teach each other. A person should be willing help others learn the skills they have acquired. Many times this will require patience when other team members do not learn easily.