I did some Scrum training for a creative agency earlier this year. The workflow at this company is not an obvious fit to Scrum as originally designed for software. To help find the best fit, I did a survey of how other agencies are applying Agile/Lean principles and frameworks to their work. A summary of my findings, with references, is in this deck at SlideShare.
There are legacy forces that work against pull systems, trying to push work into both Product and Sprint Backlogs. These include stakeholder requests, maintenance fixes and client feature changes. Scrum is designed to absorb feature requests and changes by buffering them into the Product Backlog. Maintenance work is buffered by defining a set percentage of Sprint time for fixes and paying down technical debt. Ideally, a new product is built using Agile engineering practices that make maintenance virtually unnecessary.
There are times, however, when the legacy forces overpower the Scrum machine. (more…)
I was at Agile Open San Diego last week. Thi sis annual event where smart people get together to learn from each other. I highly recommend it for next year. There are other Agile Opens in Orange County, San Francisco and Seattle.
I attended a session to discuss training for developers on Agile Teams. It was a small, passionate group. There were people from Net Objectives, a great source of technical resources and enterprise Agile transition, and Rocket Nine Solutions, an Agile consultancy I have been working with over the past year.
My modest contribution was to share some things I have learned from several iterations of technical training I developed and delivered over the years. I have not done any for a while but I still have a few relevant neurons left. I was recently at a client and had the opportunity to share with some younger engineers the things I thought they should learn to be more successful in their careers. They granted me the modern honorific of OG. If you are of my generation, you may need to look that up.
In the Agile Open session, I sketched out a suggestion on what might make a good curriculum for Agile developers. Not much of this is new. I learned most of it more than a decade ago, some 2 decades ago. For what it is worth, here is my list, in a learning sequence that makes sense to me.
Suggested Agile Developer Curriculum
- Test Driven Development(TDD)/Pair Programming
- Continuous Integration/Continuous Delivery/Code Coverage
- Programming by Intention
- SOLID Principles
- Emergent Design
- Clean Code
- Code Quality/Complexity/Dependency Analysis
- Design Patterns
You can get a lot of this in a Scrum Alliance Certified Scrum Developer course. The list would also be a great self-study course for internal engineering groups. We did some of these when I worked at Microsoft in the early 2000s. In discussion with others at Agile Open, I threw out an guessthat engineers could learn these topics in 3 months with a half day/week study if they integrated the learning into their real work. I have introduced the first 3 topics to groups in a half-day of training at several clients.
You may notice that automated acceptance testing, or story testing, is not on this list. I consider that to be a complementary but separate topic because it is trivially easy to learn. I have also gotten teams started in that in a half day.
I have heard good things about Mob Programming but have not tried it myself. Well, maybe once long ago when there were four of us “pairing”.
My favorite book on TDD is Test Driven. It also introduces automated acceptance testing.
The topic list above has links to other resources.
Do what you like with this. Learn, get better at your craft and go home each night with full confidence that the work you did today was rock solid. It is a great feeling.