Tag: Stress

Muri, Kaizen & Retros

When do you most need a retro? When you feel as though you don’t have the time for it. Muri In lean, the feeling of stress (or the impossibility of your task) is called “Muri”. It should serve as a powerful indicator that something is terribly wrong. If you feel this as a member of the team, it is your duty to stop what you’re doing (pull the metaphorical andon cord) and have a serious conversation. In common agile parlance, that is a retro, but it could just as easily be called kaizen. There may be many reasons for such a feeling. Perhaps your deadline is unreasonable with the current scope. Perhaps you are trying to centralize something on a small team that cannot support the load being put upon them. Perhaps you feel like you’ve nearly solved a problem, but have felt the same way for days and the solution continues to be elusive. Problems Just as your problems don’t nicely conform to a script such as “what went well” and “what didn’t”, your retro does not need to be so narrow. Be willing to reflect on what you’re doing, how you’re doing it, how you feel, and “why”. Be willing to have an open conversation about all these topics whenever necessary. Problems may not always arise on a two-week schedule and if they can be solved sooner then everyone is better off. Remember that the retro is also about finding solutions (or starting toward them). If you consistently talk about the same issues but take no action, that can be a source of muri! Beware of Justification Metrics and intrinsic motivation can deceive you. Your desire to “just finish it” can undermine your long term success. Your drive to do things “this way” despite lacking the time or team can make you sound like a victim. Don’t allow these justifications to enable muri. Listen to how you feel. If you feel that something is wrong, you may be telling yourself something your brain cannot yet comprehend. When tackling problems, be careful of “solutions” that justify your stress or avoid unpleasant conversations. You must be willing to accept the possibility that your perspective may be ill suited to this specific context. You must be comfortable being uncomfortable so that you can engage in the conversations that must be had. A great many problems can be solved by merely achieving a common understanding. Conversations, especially those that are unpleasant, can be the best tools in achieving this. Mirages & Solutions The solution may not be to bring in more people help the project get back on track. That can make things worse. You may be better off having the hard conversation about scope or dates. At the least, this can help you understand the relative costs of delay between the deliverables so that wise trade offs can be made. The solution may not be to expand the centralized team substantially so that they can manage all deployments for an enterprise. You may not want to staff a team of release engineers like a call center so that every deployment request can be handled quickly. You may be better off having the centralized team act as consultants to the de-centralized doers rather than doing the work themselves. This can empower the team and accelerate the progress they were aspiring to. The solution may not be to hire a consultant to solve the problem for you. Rather, all the talent you need is probably already there and you simply need to discover how to find it. This does not inspire confidence quite like rented credentials, but it gives you a chance to better learn about the team, it gives someone a chance to showcase their ability, and it gives someone within your team a growing and learning opportunity that you had been giving to the consultant. When do you most need a retro? When you feel a pit in your stomach whenever you think about it. When you cannot find the time due to the amount of work that needs to be done. When you’re dreading the conversation and just want to avoid it. When you’ve tried a dozen quick fixes and none of them have fixed it. These aren’t signs to delay. These are signs at you’ve delayed too long.

Takt Time & Waste Elimination

How does the use of sprints (takt) eliminate waste? By reducing Mura & Muri. Mura – Variability Imagine a lean auto plant with a 60 second takt. Expectations for everyone are clear. You will be done in 60 seconds. If you cannot consistently do your job in less than that, there is a problem. In 60 seconds, the next car will be ready for you. Imagine if my job takes 60 seconds, but the next car arrives at random. Sometimes it arrives in 20 seconds. Sometimes 300 seconds. I will need to worry about this. My attention will be split between doing the job and tracking incoming cars. I may even build special tools or modify the line to include staging areas. Doing this will help me manage the work, but this is an infrastructure I’m putting in place to help me manage the variability. It isn’t adding any client value. Unfortunately, I need to do this because I cannot be assured that I have enough time to do my job. If the next car is coming quickly, I may need to cut corners and just move on to be ready for it. It’s similar for creative teams. If we simply take work as it comes with no process to control it, we will invest a lot of energy into knowing and tracking the various due dates, conflicts, and needs. We may build waiting queues and layers of vetting to “speed things up” once we’re ready to start the work (if you think this will work, look at the system optimization that is lost in a production cell). A lot of mind power will be invested into just keeping everything in motion so that nothing appears to be failing. When deadlines conflict, we sacrifice testing, unit tests, or code reviews (or worse) to keep up. If we create a predictable pattern to enable delivery, people can start investing their mental energy into client problems rather than tracking the variations in our planning processes. There will be more about this tracking (managing work variation) in other articles. However, this takes a great deal of discipline. Not only must you respect your takt, but you must balance the work so that you are able to consistently deliver to your quality standards (testing, unit testing, etc.). There will be more about this balancing (managing skill variation) in another article. Muri – Stress It is that propensity to take on too much work, which creates so much stress for white collar workers. In manufacturing, the line controls flow. You can’t physically have two cars in your work station. For software engineers, you can have the entire backlog in a “doing” state and nothing will stop you. Juggling between what’s “on deck”, “getting started”, “wrapping up”, and “being supported” can spread your attention thin. The context switching alone can wear you down, let alone the greatly reduced ability to get things done due to the sheer volume of things you’re trying to do. Sprints offer a way to overcome this. At the sprint’s beginning, we plan. We plan as much as we can reasonably complete and focus on the most valuable things we can do in our limited time. This protects us from having the entire backlog in process. It focuses us onto a body of work we can achieve. This can greatly reduce the stress on team members while ironically increasing throughput by eliminating much of the context switching. In software development, the formal spring planning limits the “in process” work so it can’t overwhelm the team. If that seems overly simple, it is. That’s also why it’s powerful. Sprint plans help protect white collar workers from themselves. It makes sure their commitments are reasonable targets for completion, and this gives them both focus and satisfaction every sprint. Challenge Does your sprint process control variability in a way that enables focus? Does the team limit he work in each sprint to that which can be completed?