A common reason for disagreements is differing definitions. I once had a discussion with a friend about egoism and people’s ability to do truly altruistic acts. After an hour though, we suddenly couldn’t agree more. That was when we decided to define egoism.
Defining what done means is essential of exactly this reason. If you don't know what people mean by "done", how do you have meaningful conversations about progress and the state of work? How can you be confident when asking for estimates?
The agile team concept is one of the Scrum practices that might be difficult to fully grasp. For me at least,this is a continuous learning experience.
It is also one of the most important things to get right: and where many agile transitions go wrong. Cross-functional, self-organizing teams runs counter to the classical matrix management structure with project teams.
Many organizations do sprints, Scrum boards, burndowns, and so on, but don’t change their mindset much.
Zen values simplicity, so does agile development. Zen means introspection, a key component of Scrum as well. Additionally, Zen is the attainment of enlightenment: very similar to the feeling when you first get agile.
As promised, here's the first post in a series about the free presentation Zen of Scrum available at SlideShare.net. (It is also available as PDF here.)
Why did I name the slideshow Zen of Scrum1? In addition to the things mentioned above, Zen is a state of complete awareness where you are in perfect tune with your surroundings, ready for anything. This is a goal of Scrum, too: you should always be prepared for, and welcome, changes.
People might not like the idea of Scrum for many reasons. Three types of teams that don’t Scrum though they might have heard of it are:
1. Teams that are productive
2. Teams that think they are productive
3. Teams that don't want to be productive.
So before shifting to Scrum, think about your reasons behind migrating and if it is a good idea to start with. If you go through with it, consider how teams will react to the change and formulate a transition plan accordingly.
I have uploaded a presentation to slideshare.net, and you’re welcome to download it for free. It is also available as PDF here.
I plan to follow it up with a series of related posts. Stay tuned!
In six posts, I have written about agile roadblocks: obstructions for implementing agile processes. The time has come to conclude the series with a summary and a couple of final words.
The theme of the series has been issues you might be facing when migrating to agile development.
Agile principles are easy to understand but can be difficult to master, and the transition to agile can be as complex as the problems it tries to solve.
Scrum and Getting Things Done (GTD) are two frameworks developed with one common goal: Increase productivity.
Scrum and GTD have very different premises: Scrum is a project management framework, while GTD is a “work-life management system”. Scrum is all about the team. GTD is based around the individual.
Despite the apparent differences, Scrum and GTD have much in common. They base their success on some fundamental observations on how to become productive.
In the series about agile roadblocks: obstructions for implementing agile processes, the time has come to “Cross-Functional or Dysfunctional”.
Cross-functionality leads to autonomous teams where complete features can be developed independently. One roadblock to achieve cross-functional teams is organizational silos1. Another potential problem is the common misconception that individuals need to be cross-functional.
In the series about agile roadblocks: obstructions for implementing agile processes, the time has come to “Predicting the Unpredictable”.
One reason behind the success of agile methodologies is a new approach to estimating work.
Traditional estimations fail of at least two reasons: they are based on calendar time, and they are done for the complete project directly.
In addition, estimates are sometimes calculated by people other than the ones that will do the actual work. How's that for commitment?
In the series about agile roadblocks: obstructions for implementing agile processes, the time has come to “Man Overboard!”. (Also read the previous posts: stray team members, drowned by waterfalls and lost in translation.)
Scrum teams are supposed to consist of highly motivated, cross-functional and self-organizing people. What if someone is not on board? How do you deal with people that are not motivated and don’t want to adopt agile processes and team practices?
You might find yourself in situations where you are asked to use Scrum and have people on your team that are used to working alone, or using other methodologies, and simply don’t want to change.
Version control, also known as revision control or source control, is an integral part of software development. Like chess, it is easy to learn the basic principles but takes a lifetime to master. Many teams end up in an impenetrable jungle of branches and merging.
Having a well thought-out branching strategy is crucial. This article covers the basics of branching, and suggests a branching strategy to use: branch by purpose.
In the series about agile roadblocks: obstructions for implementing agile processes, the time has come to “Lost in Translation”. (Please read the previous posts about stray team members and drowned by waterfalls as well.)
People are eager to migrate to agile processes such as Scrum. There’s a lot of talk about sprints, scrum boards and retrospectives. One thing that is overlooked is understanding why agile works and the rationale behind it.
In the series about agile roadblocks: obstructions for implementing agile processes, the time has come to “Drowned by Waterfalls”. (Read the previous post about stray team members as well.)
Often agile processes slowly make their way into larger organizations. Parts of management may not even be aware of any changes. Others may be too rooted in existing processes and methodologies. They consider any change an annoyance that will eventually go away if you just ignore it.
So, how do you apply an agile development process when drowned by waterfalls?
This is the first post in a series about agile roadblocks: obstructions for implementing agile processes. First up is “Stray Team members”.
To share resources between projects seems to be a more common practice than one would expect. What’s worse is that often it is done seemingly without good cause. Some managers do not understand the impact this has on productivity, and the well being of the individual.
