Last night while I was putting the kids to bed my 4 year old daughter tried her typical stalling routine. “Daddy, I need to get something from downstairs”. At bedtime we usually read books in the upstairs hallway and both kids have a bedtime snack and something to drink.
I told her that she needed to be back upstairs in 20 seconds or I’d eat her snack. She paused for a couple of seconds and then took her snack and drink with her. I didn’t bother counting to 20.
Since I’m a bit of a nut, I wanted to see how my 6 year old son would manage that same problem. The first thing he did was freak out. “You CANT eat my snack Daddy!”. I could see him struggling with what to do. He wanted to go downstairs but he wanted his snack too. I could feel his anxiety building and it took him about a minute to figure out what he wanted to do. He decided to go with shovelling his entire snack in his yap before he went downstairs to “get something”. Just in case he got lost, enough crumbs were falling out of his mouth to leave enough of a trail to get back.
When I break down how they both reacted, both got what they wanted. The ‘thing’ from downstairs and their snack. My daughter experienced very little stress under the same system constraint while my son was visibly frazzled.
If you are trying to adopt Agile, whether you’re just getting started or in process of transitioning, there are many systemic forces causing people in your organization to react differently to the same set of conditions or contraints. Come to my Agile 2011 session and learn more about what you need to understand about yourself and your organization to get started with Agile.
In Part I of this series, I talked about why we were changing our processes to better align with the type of work we are doing as well as some of the business challenges and different outcomes we wanted to get. It’s been just over 2 weeks since we started and we’ve done 1 retrospective as a team so far.
I mentioned in our first post that we generally have a bad habit of considering all problems to be emergencies and our previous implementation of Kanban was more of an excuse to not prioritize and push work through. Over the past couple weeks I observed another interesting system effect. I call this the “we should” syndrome. “We should do this work” statements are usually interpreted as “drop what you are doing and go do that new thing“. These discussions usually start with managers and the workers interpret that as an order even though there is no explicit discussion or decision to do the work. This isn’t something new, I haven’t worked in an environment where this type of stuff doesn’t happen.
So here we are a couple weeks later and every standup someone is working on something that isn’t accounted for and the inputs to the team are still going around the queue. I’m probably the most anti-process person you’ll meet but if we agreed to a process, stick to it until it proves that the process needs to change otherwise you end up where you started, random chaos. Continue reading
PSL provided a wealth of learning experience for me. It’s difficult to pinpoint one specific thing, however what I feel was the most important at this point in my life was the re-enforcement of organizing people around the work.
Esther Derby’s session at AYE2010 gave me a basic understanding if this, PSL helped me experience it at a much deeper level.
All organizations have some type of hierarchy. I’ve yet to work in a company that organizes the people around the work. Instead they focus on departments and silos and making sure people are kept busy instead of focusing on doing valuable work. While I was at Lean 2011 this year, I spoke to a couple of people that work for a 60-ish person company and their software engineers are just that. Software engineers. They are ‘title less’ and while they do have people that have more skills in certain areas, they don’t have dedicated specialists.
They also talked about how they staff projects, people largely volunteer for them and they use a large visible board in their office for people to choose what projects they want to work on.
Is there any reason why this approach can’t work in your organization? Continue reading