Doing what I do for a living, I find myself often trying to explain agile concepts to folks that are relatively new to agile methodologies. Sometimes this comes up when I am teaching a class, doing a conference talk, or breaking down some idea in a blog post. I thought I'd share my approach with you guys, and a little on how I think about this, and see if you guys have anything to add.
Agile is a Family of Methodologies
Okay... so you are going to 'adopt agile'. What exactly does that mean? Well... if you are going to change how you are delivering software, it helps to start with an understanding of the methodologies and approaches that you have at your disposal. I like to start off talking about these methodologies and how they relate to each other.
- Extreme Programming
- Scrum
- Agile Unified Process
- Adaptive Project Management
- Feature Driven Development
- Dynamic Systems Development Method
- Crystal Clear
- Lean
- Kanban
What came first, the chicken or the egg? If you look at the history of Agile, the manifesto didn't come first. We had some folks in the community, folks that were already using lightweight methodologies, that came together to explore what these approaches had in common. After we have an anchor point with the various approaches, I like to talk about the principles and values that unite them. Seems consistent with how we actually evolved as a community.
- Agile Manifesto
- Declaration of Interdependence
- Lean Values
Next I like to explore what these methodologies have in common from the standpoint of how we build software in today's modern product development organizations. Each of the methodologies express different aspects of the product development lifecycle. XP is heavier on engineering, Scrum heavier on project management and team dynamics. I like to explain the methodologies in terms of how they address stuff we are already familiar with.
- Engineering
- Project Management
- Business Analysis
- Leadership
Now is a good time to explain the practices that are associated with many of the common agile approaches. Doing these practices doesn't make you agile, but if you understand how they fit into and support the values and attitudes, they certainly do reinforce an agile mindset.
- Iteration Planning
- Daily Standup
- Iteration Review
- Retrospective
- Pair Programming
- Continuous Integration
- Test Driven Development
- Small Teams
- Co-location
- Collaboration
- Information Radiators
Similar to the practices we just discussed, agile artifacts don't make you agile. These artifacts are proven to support agility and make collaboration and responding to change all that much easier.
- Backlogs
- Users Stories
- Burn-down Charts
- Cumulative Flow Diagrams
At the end of the day, it is the people in your organization that ultimately determine your success or failure with agile methods. It is important to tell them how adopting an agile methodology is going to impact what they do for a living. When I talk about roles and responsibilities, I often find myself talking about culture and the impact that agile adoption is going to have on yours.
- Customer
- ScrumMaster
- Team
- Business Stakeholders
- Managers
Scaling Agile
All but the simplest organizations are going to have to deal with the scaling issue at some point in time. Even if you are going from one team to two, or two teams to four... understanding how scaling impacts your business is an important part of the adoption discussion.
- Agile organizations are built around cross-functional teams
- Structure and culture will trump people, process, and tools every time
Final Thoughts and a Bit on Chapter Two
This isn't an exhaustive list, just the things I seem to come back to the most. It's raining here in Atlanta, so today I am doing some writing. My kids are going to drag me off the couch in a few hours and make me take them to the indoor airsoft arena, so I need to get a few words in while I have the chance. Chapter two is going to explore some of these ideas in more detail, so I expect to share some more on this approach over the next few days. Stay tuned!
Subscribe to Leading Agile
Too much information! :}
ReplyDeleteDude... that's just what I do ;-) I wouldn't say all that in one sitting.
ReplyDeleteExcellent post Mike, and very easy to digest. It is very difficult explaining Agile as it's a set of principles not simply a methodology. I think that if we can get across what bringing Agile principles into a company will mean for them, both as you said in regards to jobs and bottom lines, we can be much more successful in increasing understanding.
ReplyDeleteHi Mike,
ReplyDeleteI enjoyed this post - an interesting little read. I will point few people towards it. :-)
Here is a nice model of the Agile Manifesto that i've come across ~ Just as a point of reference for your article.
Agile Manifesto Model
Excellent post Mike!
ReplyDeleteGreat post Mike! I enjoyed the breakdown and find it pretty encompassing. A very nice outline. Look forward to the additional analysis.
ReplyDeleteGood points to be considered during a talk, but I'm sure that no one else can be an expert at the same time in all of this areas. What do you do with some questions about a specific topic?, for example about pair programming, maybe your background is not strong in some specific areas. How do you handle this?
ReplyDeleteRegards.
Carlos,
ReplyDeleteI can handle pretty much everything in the project management, organizational design, leadership, and scaling space.
My weakness is that I am not a software developer, and haven't been in a long time. I am conversant in the benefits of the engineering side of agile and why you would do those practices. I understand what risks they mitigate and have experience talking people through the techniques.
That said, I am thin in that area and defer to the technical experts on my team when I need to.
Mike