ACM webinar - April 1, 2016
(Yes, it is an April Fools' Day presentation, so there is no real YOGA process. But there are some important insights about software process in this method. See the list of "serious ideas" and "silly ideas" at the end of this article.)
The 10 rules of the YOGA method:
Some introductory comments:
After developing software for a while, my goals became
YOGA focuses on flexibility
Software quality is going to be important in the future.
People say that you should go back and examine your mistakes, and they say that if you don't analyze your mistakes, you are going to repeat them. I don't believe that is true.
The data on software development says that improvement is never steady. Even in the oldest software engineering data they found that there is always a constant number of bugs in every release.
Our technology is always changing, so it is important to forge ahead.
Although the first couple of releases of a product may have a lot of defects, we find that starting with the third release of a product, the number of customer-reported bugs stabilizes. Every subsequent release will have about the same number of bugs.
Rational plans never work. You can lay out process with a series of planned decision steps -- but the plan never works. The customers change their minds, the environment might change, the designers might make a mistaken assumption, management changes priorities, or whatever. Project managers go crazy trying to track everything.
Follow the advice from the classic David Parnas article about "faking" a rational process.
Meditate on the code every day. This is one of the places where yoga and software development come together very closely.
As a software engineer, you care about how hard or easy it is to make changes to your code.
Software development is a process of making changes, so you want to know what is easy and what is hard. We should do what we can to make change easier.
We should also look at what is "worth" changing.
Some developers put things into the code that make it almost impossible for someone else to change it.
You should meditate on the code you are working with (which might be code written by someone else). Do the meditation for an hour a day, thinking about change.
Daily Strum meeting -- it is stand up meeting with one person strumming a guitar to keep everyone calm and relaxed.
The meeting is for everyone to share -- to learn what everyone else is doing.
There are variations on how to vote. But the idea is to get a consensus on what changes most people think are worthwhile.
It may be a tense meeting, which is why we have the guitar player.
The Strum meeting is usually run by the YOGA master, who knows how to get everyone relaxed.
Yoga is about flexibility. The same thing about software development.
We want code to be flexible and sustainable. So we want to make a change per day.
You choose a change in the Strum meeting - a change that most people like and are familiar with.
I think of changes in terms of Product Line Engineering.
The more successful your system is, the more variety of requests for changes you will get. You can't predict all of the changes you will be asked for, but you are better off if you do some thinking about change in advance.
It pays to think about possible changes ahead of time (commonalities and variabilities). Write them down -- you can discuss variabilities in the Strum meetings.
Rotate roles on a regular basis. You might want people to go from architect to developer to tester to project manager. If you rotate the roles, you will be in better shape when someone leaves the team. The idea is to maintaining "knowledge" in the team -- which makes it more sustainable. You are maintaining information that everybody needs and can use in the project.
When you go from one role to another, you might move from one office (or working space) to another. I worked for a company many years ago that forced people to move offices every 6 months. They thought that it kept us sharp and it kept us from accumulating too much junk.
Many yoga exercises are about being able to "rotate".
Get your developers to practice refactoring parts of the code. The "core group" is defined to be the set of people who make 80% of the changes to the code base. And it is true that we usually have a very few people in our organization that are really good at making changes.
You want to foster greater productivity... the ability for your developers to make more changes over time. You should have your people practice doing refactoring. You might even have a little contest. You can take part of the Strum meeting and have people demonstrate how to refactor, or compete in making changes to some code.
Note that when you transfer a code base to an "offshore" group, the productivity -- the number of lines of code changed per developer per year -- falls dramatically.
Improve your balance... you want your team to be balanced. You want to have a good working relationship with your team members. Make sure you understand the knowledge and skills of team members, and ensure that the knowledge and skills are "complementary" (fit together). It is also good to "complement" your teammates -- to say nice things and recognize when they do a good job.
For long-lived projects, you need to capture the "essential knowledge" that people need to be able to make changes to the code. Make sure that the essential knowledge is not lost. Team members need "mentors" to help this happen. Team members may also review each others' work.
You can practice balance during the Strum meeting. Have team members stand on one foot and discuss their changes during the meeting.
"Sun salutations" is part of yoga. It is a way for the leader to help people start the day.
In yoga, it is a series of exercises and postures you use at the start of the day. It strengthens muscles, stretches muscles, clears the mind, and get some aerobic exercise.
End the day with deep relaxation. Lie down, close your eyes, focus on your breathing, try to clear your mind of everything. The yoga master will lead it.
It is good for the yoga master to have a chant when everyone is relaxed -- like UUUMMMLLL.
Seth likes doing relaxation both at the beginning and the end of the day.
This is just a set of principles. It is up to you to define the process -- artifacts, roles, activities, and schedules. It is especially good to have some ways to identify risks.
You might have a family of processes. Every process has some commonalities -- but there are variabilities that may be used to define different "processes" from the same family.
Be careful to use "just enough process" -- don't make it too complex.
Strum meetings and Scrum meetings are both daily, but they work differently. We have the guitar, we get people to stand on one leg, we talk about changes - I don't think these happen in a Scrum meeting.
In YOGA, we spend more effort on design than agile method do.
Seth wants to explore the ideas of "juggling" in the software world.
He plans to set up a website about "Sustainable Software."
He is exploring alternative models for running software product development. For example, we might organize software development where developers "bid" on pieces of the development work.
Main "serious" ideas:
This work is licensed under a Creative Commons Attribution 4.0 International License