Being Passionate
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
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.
The tide is changing
By · CommentsToday was one of those days when one sees months of effort pay off. The project manager and QA manager are really going to give the team a chance to do genuine agile development over the next 3 months. Our overall deliverable is not until the end of September but we will have a chance to work with QA and actually produce sequential releases for for multiple projects. This should be challenging and fun.
Micromanaged
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
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
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.
Communicate, communicate, communicate
By · CommentsCommunicate can I say it enough. Agile development requires and enhances communication. We had an unfortunate situation where lines of communication broke down for a project. It occurred with requirements and QA testing.
The scope of the requirements were not clearly understood by the product owner. Actually we do not have direct communication with the product owners and are using a proxy. Fortunately there are still drawing on the window which clearly showed the scope of the project.
Then we had miscommunication with the QA test plan. The test plan was never reviewed. and had tests that were outside of the scope of the project.
The project is also behind schedule and requires special exemptions to get into the current release.
I hope you understand that this was not a Agile project. These problems are ones that would have been exposed sprint plans and reviews.
What are you reading today?
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
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
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.