September 29, 2014
By Johanna Rothman
I posted my most recent Pragmatic Manager newsletter, Scale Agile With Small-World Networks on my site.
This is a way you can scale agile out, not up. No hierarchies needed.
Small-world networks take advantage of the fact that people want to help other people in the organization. Unless you have created MBOs (Management By Objectives) that make people not want to help others, people want to see the entire product succeed. That means they want to help others. Small-world networks also take advantage of the best network in your organization—the rumor mill.
If you enjoy reading this newsletter, please do subscribe. I let my readers know about specials that I run for my books and when new books come out first.
September 29, 2014 02:59 PM
September 23, 2014
By Johanna Rothman
If you are organized as platform team, middleware, and front-end teams, you have a component team organization. That made sense at one point in your history. But if you are transitioning to agile or have transitioned, and if you want to use agile on a program, that might not make much sense now.
If you have a program, you have many people in your teams. Your platform team might not be 7 people, but several teams, maybe 50 people, if you are large enough for a program. Your middleware teams could be another 100 people, and your front-end teams could be another 100 people. You have lots of people and lots of teams.
I bet you do not have an even ratio of platform, middleware, and front-end teams. You have experts, here, there, and everywhere. And, if you are anything like my clients, you have trouble releasing features in an agile program.
What are the problems?
- You have experts embedded in a wide variety of teams
- The experts need to multitask to serve a variety of projects, so you incur a cost of delay to multitasking and queues
- You are not releasing features. You have trouble when the components come together.
Even if the teams are agile, your program, the collection of projects is not agile.
What can you do?
You can ask the organization to try this as an experiment, for no longer than 2 weeks:
- The only measure of success is running tested features. And, no one, especially no manager, gets to compare teams. This is an experiment that the organization is going to learn from. Some teams will have small and easy features. Some teams will not. This is not a competition. If you start comparing teams, the teams will game this measure and the organization will lose the learning. It’s not about the number of features. It’s about learning how to manage the stream of features through feature teams.
- Ask three teams to volunteer: one platform, one middleware, and one front-end team. If more teams want to volunteer, fine. But you need three.
- Those teams stop multitasking. Those teams agree on one ranked backlog among the three teams. (I know, this might be the most difficult thing your organization has tried. I know you have experts. Ignore the fact you need experts everywhere. Agree on only one ranked backlog.)
- Ask these three teams to self-organize as feature teams for now. No changing managers. No changing desks. They get to decide how to organize. If you are a manager, no decreeing who is a feature team with whom. Let the teams decide who is on what team. This works best in one large room. However, I have seen geographically distributed teams who were desperate to release a feature do this over distance.
- Ask the Product Owner for these teams to make the stories as small as they can make them, preferably one or two team-days or less. This could be a huge challenge for the Product Owner. That’s okay. This is an experiment. I recommend a kanban board and limiting work in progress for this experiment.
- Tell the teams that if they don’t have the expert they need for a story, that’s okay. They can pair, swarm, or mob together to get the story done. But, they are not allowed to interrupt another team.
- The teams work on their backlog for this experiment (not any longer). They see what happens when everyone works in feature teams of their own making and no one multitasks, to get features to done. Remember, this is an experiment.
- Retrospect at the end of this experiment so they can see what happened.
- Decide what to do next. This is an experiment.
To sum: One self-organizing team, composed of platform, middleware, and front-end people. One backlog. One product owner. No longer than two weeks. Visualize the workflow. Limit work in progress. The only measure of success is running, tested features. No multitasking. Retrospect at the end. See what happens.
There are many things that can go wrong. But, there are many possibilities of learning here. This works best if the managers step back and don’t interfere. It works best with collocated teams. You can do this (and I have) with geographically distributed teams.
When I’ve facilitated this, the teams learn tons about how to work together and what they needed to do for their program. In several organizations, they wanted to do this again as an experiment.
Managers have to allow the teams to organize the way the product requires. Otherwise, you have Conway’s Law in spades.
When I have done this, I have had these results:
- Most of the time, the teams were able to finish some of the features in their backlog without too much trouble. These features required some of the team to work together, either discussing the feature, or pairing.
- They were able to finish most of the features in their backlog with a little trouble. These features required the entire team to work together.
- Some of their features were too large to finish in the timebox.
These results don’t surprise me. I bet they don’t surprise you.
Every so often, teams have trouble finishing any features. They learned that they did not have sufficient expertise to do anything on their features in their backlog. One team spiked a feature for a day, swarming on it. They had more questions than when they started. They needed an expert who was in another team.
If you put the focus on releasing running, tested features, that is what people will do. But you have to focus on it.
Component teams aren’t bad, per se. But component teams don’t get you running, tested features. This is one possibility. Based on your experiment and reflection, you could try something else.
September 23, 2014 11:24 AM
September 19, 2014
By Johanna Rothman
Way back when I was a developer, my professors taught me structured design and design by contract. Those were supposed to be the silver bullets for programming. You see, if you specified things enough, and structured things enough, everything would all work out.
I thought I was the only idiot that structure and specification didn’t work for. Why did I have to iterate and increment?
At my first job, we had design reviews and code reviews. I learned a lot. I worked on a government contract, and the government mandated those reviews. They were useful, and they were supposed to be a silver bullet. Because we implemented features (yes, back in the ’70s, we implemented features), the reviews were helpful in the small.
But, I worked on a program. There is just so much design by contract can do for a program. I was in Boston. I had questions for my counterpart in New Mexico. I was not allowed to talk to that person. (To this day, I don’t know who that person was. That person was part of another subcontractor.) I had to send my questions up through the project management layers to the program team and down the other side. My questions never did get answered. I left that company before I knew if my code worked with the entire system.
I transitioned into project management, program management and people management. I have seen my share of fads, bullets, and fixes for the software departments.
As a director in the early ’90’s I got sent to TQM school (Total Quality Management). My company thought it would change the way we managed, and revolutionize our organization. It would be our “silver bullet.” I’m pretty sure those were somebody’s words. They weren’t mine.
I got a certificate for my five days of intensive training (powerpoint and calculations). I might still have it somewhere.
I became excellent at calculating many costs: the cost of quality, the cost of not doing things right, the cost of technical debt, even what we might consider the cost of delay. I dutifully explained these costs to my senior management. Was I able to persuade my company of the cost of not doing the right thing, even though I was a middle manager, a program manager, and had been TQM’d?
No. My management was too concerned that doing things “right” would prevent us from making money. I had data—yes, data—that proved them wrong. But their belief systems overcame my data.
Later, after I started my consulting business, many of my clients fell into the ISO 9000 and the CMM/CMMI quick fix/silver bullet traps. The ISO joke made the rounds: “You could specify a cement life jacket with ISO, as long as you define the right process for creating it.” Well, no. But the jokes still persisted. (Many people find value in ISO. Some do not.)
And, with the CMM/CMMI? Oh, my clients had binders full of documentation, but they weren’t releasing software. They hired me on the side, because their silver bullet of CMM/CMMI process wasn’t working. Somehow, my approaches of timeboxes and increments, and iterations, and thinking about their projects was. (Many people find value in using CMM/CMMI. Some do not.)
Now we have agile. If you read my work, you know I lean towards agile and lean. At the same time, I say that agile is not for everyone. Agile is not a silver bullet.
We have no silver bullets in software.
We have difficult problems to solve. We must think about our approaches, each and every time. We must consider our context. That why I wrote Manage It! Your Guide to Modern, Pragmatic Project Management. Because every single project is unique. That’s why I’m writing Agile and Lean Program Management: Collaborating Across the Organization. That book is a principle-based approach to program management, to scaling agile past one or two teams. Not a one-size fits all approach to program management.
And, because we have no silver bullets in software, and because we have no quick fixes, my management myth this month is We Need a Quick Fix or a Silver Bullet.
It’s very tempting to think that transitioning to agile might be a quick fix or a silver bullet. Transitioning to agile or lean might help you. It won’t be quick.
Any transition is a change. Change takes time. Change is learning. Developing software is learning. You can help yourself learn faster with some approaches: make value obvious instead of tasks, get feedback often, visualize your work, etc. For many of you starting your agile journey, these are cultural changes.
The more you challenge the culture, the longer the change takes because people need to learn what to do and how to work. Cultural change is not a silver bullet. It is certainly not a quick fix.
Read Management Myth 33: We Need a Quick Fix or a Silver Bullet.
September 19, 2014 01:33 PM
September 16, 2014
By Johanna Rothman
Do you have projects where you can’t predict an end date? These tend to be a job search, a change project, and with a tip of the hat to Cesar Abeid, your life. I like to call these “emergent” projects.
You might prefer to call them “adaptable” projects, but to me, every project has to be adaptable. These projects are emergent. You need to plan, but not too much. You need to replan. You need to take advantage of serendipity.
My column this quarter for projectmanagement.com is Applying Agile to Emergent Projects. (Free registration required.)
September 16, 2014 11:50 AM