Both Ron Jeffries has commented on my Event vs Polling ideas and so has Travis Illig about having fun with status meetings.
They both use the same argument: We use Scrum standup meetings, we ask what we did, what they are going to do and what is stopping them. This is enough information.
I am all in for doing Scrum. I have had my fair share of waterfall development, XP and Scrum, and Agile is far better then the waterfall ways.
The stand up methods and scrum are great for putting some order in a complex and changing environment. But there is a small but important issue, it is too easy to focus on giving excuses.
Why didn’t we do what we promised: Well the build server didn’t work and we waited for IT to install our system, but they didn’t come. We can always find reasons for what is stopping us.
Stop giving excuses
I hate excuses, they don’t help at all.
I call focusing on solving problems and living up to your word: growth.
Its the ability to do get better and better at what you are doing. It is not waiting for IT to do things but learning how to do something about it ourselves (notifying management of the delay so that they can help is also doing something about it).
Lets see what happened to Travis (you can read his comment, I am going to use Travis as an example here, but it could be any team lead). Travis is on many teams, and he needs to go to many different stand-ups, so Travis is polling the teams, to do this the standup have to be as short as possible because it takes up valuable time, so no problems are solved, just raised. Also notice the complexity that is happening here, the standup now have to be synchronized so that people who are on a few teams can be there.
Turn the tables
Lets see what will happen if we did something else, lets do it the other way round. Instead of polling and trying to get information and finding different ways to share that information. Lets have a system that the relevant information is pushed to the right place at the right time, and solved swiftly.
Here is one way how. I call it Integrity Management.
The hands on employees are the ones that have the most knowledge of what is working and what isn’t. We want them to choose what information is relevant to push.
In the weekly meeting each team lead commits to what they will do that week. This is a commitment, not a “we will do our best” or a “we will do the highest priority” but a weekly commitment.
There are daily standup’s within each team, but Travis doesn’t need to be there, because once a team knows that it is missing its mark, they tell all the team leads. Travis as a team lead gets the ‘event’ and can help the team find a solution (Call it a Just In Time Information, why poll all the time?). Travis can then mentor the team on how to solve these problems, and can even ask them commit to doing those actions. In our example, there is an event that team A is behind schedule because of an IT problem. We can ask the team what they can do to solve it, and they might come up with a few solutions: (Note that they are all controllable actions)
- We can nag IT again
- We can do it on the old machine
- We can install it ourselves
We can then help choose the correct way. This helps the team grow because they actually brought up the solutions themselves.
This is great, but Travis still has missing information, suppose the team decided that instead of waiting for IT, they go and do it on the old machine. Here is where talking about Dilemmas works wonders. Once the team lead says in the following meeting, “We didn’t want to wait for IT, so we decided to do it on the old machine”, Travis can point out that there is a better way to do it, but hey, they did manage to do their job! And now other teams know how to solve these problems too.
Using Integrity we focus on solving problems, not raising them. Did you know that 90% of the problems we raise in Typemock Management Meetings are solved in under 10 seconds. Either some other team member helps out, or if it is complex we meet later but we have to come with several solutions too, and these are solved quite quickly. Sometimes, the complex meeting never happens because the team solved it already while thinking about the different solutions.
Become a solution oriented organization. Focusing on solutions, will help your team grow. Integrity Management helps you focus on solution making.
I think there are a couple of things that may have been missed in my comment about stand-up meetings.
First, our teams are already highly communicative. If there’s something blocking, then generally speaking, relevant folks on the team already know – before stand-up happens the next day. When someone needs help with something over the course of the day, they ask for help. The stand-up is there to bring it to the attention of the people who don’t already know so if there are additional people interested in or capable of helping, they can follow up after the stand-up. For the folks that can’t help or are already mired in higher-priority things to do, their time isn’t held up and they can get about their business.
Second, the folks I work with are pretty highly competent. I trust them to get things done the right way. Do mistakes get made? Sure. Everyone makes mistakes. Do problems sometimes get solved “the wrong way?” Again, sure, sometimes, but that’s going to happen. The important thing is that we learn from these mistakes and grow from them. (These things get reviewed in retrospectives and, if changes need to happen, those change get prioritized as new work items.)
If everyone is involved in every decision every step of the way, it turns into a “How many engineers does it take to change a light bulb?” scenario. Or micro-management, which is worse. Involving relevant people at the correct time is the key to success and effectively managing time.
Using your IT example, what would normally happen on my team(s) would be that the folks encountering the problem would figure out how to characterize it and come up with some possible solutions. If there’s a clear winner that will help us get our jobs done and not be detrimental long-term, that’ll just happen. If there’s a question on which approach to take, though (maybe some cost/benefit trade-offs), the team member(s) with the issue will immediately seek assistance from other members on the team who might be able to help. That smaller “inner team” will determine the best solution, execute, and let the rest of the team know what the solution was. That communication could happen in any appropriate form – during a staff meeting (not stand-up; stand-up would be “we unblocked this issue” but not the full detail on the resolution), on the wiki, via email, etc.
And, of course, if no solution was reached, then the mention of a “blocking item” gets made at stand-up and relevant folks can stay behind after that to discuss the issue while letting the rest of the team get on with things. That means it never goes more than a day without relevant people getting involved.
This mechanism works really well and has the benefit of addressing the problem before we have to get everyone in the room for a status meeting.
If something sits on the “blocked” list for more than a couple of days, we get more people (and/or management) involved to get the issue unblocked. And, of course, you don’t have super-long sprints (maybe one-or-two-week sprints?) so the longest anything can go with the “excuses” is one sprint duration. After that, the blocking item becomes re-prioritized and handled in a more direct fashion as a first-class work item.
I think it’s two different ways of accomplishing the same thing – addressing risk earlier, coming to better solutions faster, and helping the team to grow and become more self-managing.
Thanks for the explanation Travis, you are probrably right, it is different ways of accomplishing the same. I would love to actually see how these team work, and I am sorry if I misunderstood you and took you as an example (I hope you don’t mind).
There is still a small difference, that might (or might not) make a difference, and I hope that I have managed to convey it.
Do we focus on the responsibility to raise the event?
Do we talk about problems or about solutions?
Do we free management from asking about the status?
Does management get the needed information, to enable you to grow?
I hope that there are some tricks that you can experiment with and see how they work in your team.
No problem at all. It’s good to talk about different stuff – how else do we learn? (BTW, I like this series on integrity – good stuff.)
In answer to the questions…
* We raise an event if it needs to be raised. The important thing there is to increase the signal-to-noise ratio. If an event gets raised every time someone has a hangnail, it turns into “the boy who cried wolf” and folks stop paying attention to events that get raised.
* We talk about the problem enough to characterize it and understand the context. From there on out, it’s solutions, baby.
* Management doesn’t have to proactively ask about status because they’re in the loop all the time. They have access to the work item tracker so they can see what’s done, what’s left, and what’s in progress; they participate in the stand-up meetings (listening in, not reporting), and the team involves them when an “insurmountable” road block is there.
* We have regular team-wide and individual discussions with management about both project and non-project things to help keep us growing not only in the context of the project but also in the company and our own personal careers.
I can’t speak for other teams, but the group I’m in right now has an excellent manager who has figured out the exact balance of how much to be involved and how much to let us handle things. When we need help, we know he’s got our back, and we’re in constant communication through various means so he always has a “pulse” on how things are going in both project and non-project areas.
That said, there’s always room to learn, so seeing some of the things you’re writing about is really educational. I’ve been taking some of it back to the group to talk about in our weekly staff meeting (which is both project and non-project discussion). Keep it up!
Thanks Travis,
It is great to hear that you are enjoying the series (I’ve got loads more coming, and I haven’t even got to personal/team-wide meetings)
I will try to answer the Signal-to-Noise issue in another post (I think that being in the stand up meeting could be noise to management)