Author Archive
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.
Competent Team Members
Posted by: | CommentsA premise of Agile is to have teams of competent members. Agile only works well of you have good team members. Here are criteria that one should look for in a team member:
- Will they fulfill their commitments? When they promise to do a task can you trust them? Agile is about meeting commitments, taking responsibility for them. and truthfulness. There is no room on an Agile team for lazy developers. I know we may incorrectly estimate the time it will take to do a task but you will only do this so often if you know you have to meet that commitment in a sprint.
- Are they avid learners? What was the last book they read in their field? What is the last book they read outside their field? How many seminars have you attended? What are your overall learning goals? It is so easy to stagnate. We all need to be stimulating our minds.
- Do you work well with others? We work together and may disagree with each other but we are team with a common commitment.
Adopting agile in large organizations
Posted by: | CommentsIs this how it happens in most large development groups “adopting” agile?
More important from a business perspective, the ability to compete
and make money with the potential power of lean and agile principles
has been squandered by doing agile rather than being agile.
We encourage those that want to realize enterprise agility to take
the time to learn the implications of values such as responding to
change over following a plan, and to take the time to discuss and
share these insights with others.
p 146 – Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum
Cargo Cult Process Adoption
Posted by: | CommentsWhen you say you are adopting agile are you really doing cargo cult process adoption. Does this describe what your organization is doing?
Adopting pieces of an idea, such as name, without understanding the underlying principles. Consider: “We adopted Scrum. Our Sprint is the length of our project. The Product Owner decide the items in the Sprint and the project manager acts as a Scrum Master. He make the sprint Backlog and assigns the task to people in the team”.
p. 261 – Scaling Lean and Agile Development: Thinking and Organizational Tools for Large-Scale Scrum
Adopting agile methods
Posted by: | CommentsThink about this…
Are you doing Agile or are you Agile ?
Unless your organization is agile, agile methodologies are going to do very little good. They are but another process in a brittle organization.
Software reflects company organization
Posted by: | CommentsThis quote if from an article published in 1968 Datamation magazine:
…organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations. We have seen that this fact has important implications for the management of system design. Primarily, we have found a criterion for the structuring of design organizations: a design effort should be organized according to the need for communication.
http://www.melconway.com/research/committees.html
When adopting agile methodologies it is so important to make organization changes. With out these organizational changes you will not have successful agile adoption.
Agile at work
Posted by: | CommentsWe are now entering a phase at work where all of our projects are going to the Scrum methodology. I am not sure the people heading this up really understand how the methodology is to be used.
I know the my immediate manager has real concerns about the approach we are taking. His real concern is that we are setting ourselves up for failure.