Starting this evening, I will be attending the Agile Coach Camp in Durham, NC. As the only registration fee for attending the ACC is to submit a position paper on a topic of interest to you, I submitted the following abstract.
I also want to emphasize one important point to avoid having to defend a position that I'm not taking. This opinion of mine revolves around the adoption of agile practices. It in no way is an attempt to water down agile, as every individual practice discussed below certainly adds value and should be part of the full vision for any team attempting to go agile. This opinion simply revolves around the idea of getting the most bang for your buck up front so that you can get all of the nay-sayers on board the agile train sooner than later.
Review of the 80-20 Rule
The 80-20 Rule is typically explained as for any given "effort", the first 80% of the results you are looking for will be accomplished with only 20% of your time and energy, while the final 20% of the results will take 80% of your time and energy. When applying this to the adoption of agile practices in software development efforts, the gist is that only 20% of the ideas/topics will get you 80% of what you were looking for when you decided to start using agile practices.
Review of Agile topics
For the sake of discussion, I'm going to use part of James Shore's table of contents from his book The Art of Agile Development. The following is Part II - Practicing XP from his ToC, as these are the concrete practices that his book discusses:
My 20% - Take 1
Seeing how James broke out the 37 practices into 5 concept areas, that makes it easy for me to make my first arbitrary application of the 80-20 Rule and grab Chapter 7 (Releasing) from above as the one concept area that you will get the biggest bang for your buck on. As software developers we get paid to produce working software. I've seen many a team over the past 15 years get caught up when releasing new versions of their software. Some developers spent days to weeks just trying to get the code to compile. Others had to "wing it" during the deployment of the code to a test server (the consummate "it worked on my machine" excuse). If you can't look at your current situation and proudly say we have the whole release process down pat and can consistently get new releases out with minimal effort, then start with this chapter.
My 20% - Take 2
Given the first application of the 80-20 Rule above to the 5 concept areas, this second application of the rule is going to be across the 37 practices (20% of 37 = 7.4 practices). My list of the 8 practices out of James Shore's 37 practices are:
#1 - Thinking - Root-Cause Analysis
James Shore's 99 words description:
James Shore's 99 words description:
James Shore's 99 words description:
James Shore's 99 words description:
James Shore's 99 words description:
James Shore's 99 words description:
James Shore's short description:
James Shore short description:
Hopefully this sparks some level of discussion for this weekend's Agile Coach Camp. If not oh well...
The Application of Pareto's Principle to the Adoption of Agile PracticesSo I figure why not put some more concrete thoughts together before the ACC starts. This post is the first of probably a couple posts on this topic, with probably at least one being a follow-up if my topic gets accepted as a discussion topic. Seeing how I average roughly 5 hits/month on this blog, it wouldn't hurt to get a little more traffic!
If you believe in Pareto's Principle (otherwise known as the 80-20 Rule), then you believe that it can be applied literally everywhere. At its heart, Agile practices are about doing what works and ignoring the rest (at least until the time is right). In a world where people are constantly searching for silver bullets, getting distracted by zealot turf wars, and feeling the crunch of deadlines, novice adopters of Agile practices need to learn what out of"agile" is immediately important for their situation, and what they can safely ignore until a latter point in time.
I also want to emphasize one important point to avoid having to defend a position that I'm not taking. This opinion of mine revolves around the adoption of agile practices. It in no way is an attempt to water down agile, as every individual practice discussed below certainly adds value and should be part of the full vision for any team attempting to go agile. This opinion simply revolves around the idea of getting the most bang for your buck up front so that you can get all of the nay-sayers on board the agile train sooner than later.
Review of the 80-20 Rule
The 80-20 Rule is typically explained as for any given "effort", the first 80% of the results you are looking for will be accomplished with only 20% of your time and energy, while the final 20% of the results will take 80% of your time and energy. When applying this to the adoption of agile practices in software development efforts, the gist is that only 20% of the ideas/topics will get you 80% of what you were looking for when you decided to start using agile practices.
Review of Agile topics
For the sake of discussion, I'm going to use part of James Shore's table of contents from his book The Art of Agile Development. The following is Part II - Practicing XP from his ToC, as these are the concrete practices that his book discusses:
5. Thinking (1. Pair Programming, 2. Energized Work, 3. Informative Workspace, 4. Root-Cause Analysis, 5. RetrospectivesThe above chunk of his ToC represents a total of 37 practices across 5 concepts areas. As this opinion paper is not about paraphrasing James Shore's book, I will not make any attempt to describe any of the above practices any more than is necessary to make my points. If you are unfamiliar with any of the valuable practices that he describes, buy and read the book.
6. Collaborating (1. Trust, 2. Sit Together, 3. Real Customer Involvement, 4. Ubiquitous Language, 5. Stand-Up Meetings, 6. Coding Standards, 7. Iteration Demo, 8. Reporting)
7. Releasing (1. "Done Done", 2. No Bugs, 3. Version Control, 4. Ten-Minute Build, 5. Continuous Integration, 6. Collective Code Ownership, 7. Documentation)
8. Planning (1. Vision, 2. Release Planning, 3. The Planning Game, 4. Risk Management, 5. Iteration Planning, 6. Slack, 7. Stories, 8. Estimating)
9. Developing (1. Incremental Requirements, 2. Customer Tests, 3. Test-Driven Development, 4. Refactoring, 5. Simple Design, 6. Incremental Design and Architecture, 7. Spike Solutions, 8. Performance Optimization, 9. Exploratory Testing)
My 20% - Take 1
Seeing how James broke out the 37 practices into 5 concept areas, that makes it easy for me to make my first arbitrary application of the 80-20 Rule and grab Chapter 7 (Releasing) from above as the one concept area that you will get the biggest bang for your buck on. As software developers we get paid to produce working software. I've seen many a team over the past 15 years get caught up when releasing new versions of their software. Some developers spent days to weeks just trying to get the code to compile. Others had to "wing it" during the deployment of the code to a test server (the consummate "it worked on my machine" excuse). If you can't look at your current situation and proudly say we have the whole release process down pat and can consistently get new releases out with minimal effort, then start with this chapter.
My 20% - Take 2
Given the first application of the 80-20 Rule above to the 5 concept areas, this second application of the rule is going to be across the 37 practices (20% of 37 = 7.4 practices). My list of the 8 practices out of James Shore's 37 practices are:
#1 - Thinking - Root-Cause Analysis
James Shore's 99 words description:
My take on it:When mistakes occur, blame your process, not people. Root-cause analysis helps. What allowed the mistake to happen? What will prevent them in the future? Assume people will continue to make mistakes and build fault-tolerance into your improvements.
One approach: ask "why" five times. Use it for every problem you encounter, from the trivial to the significant. You can apply some solutions yourself. Some will require team discussion, and others need coordination with the larger organization.
When mistakes become rare, avoid over-applying root-cause analysis. Balance the risk of error against the cost of more process overhead.
This practice is actually a twist on the 80-20 Rule in that it focuses you in on the issue that actually does need to be worked on rather than the issue that you either think needs to be worked on or worse case, the issue that you simply would like to work on.#2 - Collaborating - Trust
James Shore's 99 words description:
For maximum productivity, team members must rely on each other for help. They must take joint responsibility for their work. Trust is essential. To improve trust, foster empathy. Learn about your teammates' joys and concerns. Sitting together helps, as does eating together. Preserve productive teams by keeping them together for multiple projects.My take on it:
Organizational trust is also essential. Be energetic, deliver on your commitments, and be honest about problems. Show that you care about your stakeholders' goals. Promote your work through friendly openness. Always be honest about your achievements. Avoid the temptation to whitewash problems or misrepresent partially-done work.
In life as a whole a lack of trust leads to a constant downward spiral of every relationship. In agile, we are talking about teams, including both developers and customers, and therefore we are talking about relationships. Without trust, the process is going to fail.#3 - Collaborating - Real Customer Involvement
James Shore's 99 words description:
To widen your perspective, involve real customers. The best approach depends on your market.My take on it:
Personal development: you are the real customer. Congratulations. Go forth and write algorithms.
In-house custom development: turn your real customers into on-site customers.
Outsourced custom development: get real customers to be on-site customers. If you can't, stay in touch and meet face-to-face frequently.
Vertical-market and horizontal-market software: beware of giving one customer too much control. Appoint a product manager to understand customer needs. Create opportunities to solicit feedback. Examples: customer review board, beta releases, and user experience testing.
In my corner of the world, teams of "consultants" attack projects with little to no subject matter expertise but armed with years of experience in producing working software. This demands that customers are involved throughout the process, as only the customers have the subject matter expertise necessary for the project's success.#4 - Releasing - "Done Done"
James Shore's 99 words description:
A story is only complete when on-site customers can use it as they intended. In addition to coding and testing, completed stories are designed, refactored, and integrated. The build script builds, installs, and migrates data for the story. Bugs have been identified and fixed (or formally accepted), and customers have reviewed the story and agree it's complete.My take on it:
To achieve this result, make progress on everything each day. Use test-driven development to combine testing, coding, and design. Keep the build up to date and integrate continuously. Demonstrate progress to your customers and incorporate their feedback as you go.
Seeing how I called out Releasing as the single most important concept area, I'm going to go forward and proclaim that this particular practice is the single most important practice of all. Teams must be able to demonstrate progress daily and the sub-practices of test driven development and continuous integration are fundamental to enabling that.#5 - Planning - Vision
James Shore's 99 words description:
Every project needs a single vision, and the product manager must unify, communicate, and promote that vision.My take on it:
Distance between visionaries and the product manager increases error and waste. If you only have one visionary, the best approach is for him to be product manager. Alternatively, use the visionary's protogé.
Some projects have multiple visionaries. They need to combine their ideas into a unified vision. The product manager facilitates discussion and consensus.
Document the vision with what success is, why it's important, and how you know you've achieved it. Post it prominently and involve your visionaries in planning and demos.
Without a vision, a team can never confidently answer the question "is this topic important?" And without being able to answer that question, teams can get caught up in building software that they think is needed, without being able to justify it. That ultimately leads to lost productivity when they incorrectly answer that question.#6 - Planning - Release Planning
James Shore's 99 words description:
Maximize your return on investment by:My take on it:
1. working on one project at a time;
2. releasing early and often;
3. adapting your plans;
4. keeping your options open; and
5. planning at the last responsible moment.
Use timeboxing to control your schedule. Set the release date, then manage scope to meet that date. This forces important prioritization decisions and makes the endpoint clear.
Prioritized Minimum Marketable Features (MMFs) and stories form the body of your plan. Demonstrate your progress as you develop and use that feedback to revise your plan.
To minimize rework, develop the details of your requirements at the last responsible moment.
Some adopters of agile think that agile is all about "no documentation and no planning". They couldn't be more wrong, and thus why I'm including this practice. As James Shore points out, agile planning is about planning and adapting to changes.#7 - Developing - Test Driven Development (TDD)
This is in contrast to project managers of the past who created a project plan in MS Project at the beginning of the project and God help you if you as a developer created a situation where that project manager had to open MS Project after the project started to adjust the plan based on new information.
While I don't believe that there is anything particularly wrong with using MS Project, when using it in an agile environment the project manager maintaining the plan must update it weekly. If they don't do this, then they need to either throw out agile or throw out MS Project.
James Shore's short description:
We produce well-designed, well-tested, and well-factored code in small, verifiable steps.My take on it:
From a code construction point of view, if your team is not already using TDD, adopting TDD will raise the level of quality of the software that your teams are delivering. Simple as that.#8 - Developing - Incremental Requirements
James Shore short description:
We define requirements in parallel with other work via living requirements documents and working incrementally.My take on it:
Even in the best of the waterfall projects of days gone by that I worked on (and apparently even on the ones that I didn't), the up front requirements phase never produced a complete set of requirements. The agile practice of incremental requirements simply accepts that as a fact and creates a solution framework for continually dealing with it as the norm, rather than treating it as scope creep and denouncing it as something unexpected and bad.Closing Thoughts
Hopefully this sparks some level of discussion for this weekend's Agile Coach Camp. If not oh well...
