Most of what happens to a firm is a consequence of what it does, not of what is done to it. - Russel Ackoff


It is really common to hear people in organizations blaming and complaining about external factors that contribute to make their knowledge work environment somehow problematic. In his book, Recreating the Corporation, Russel Ackoff describes how the forces of systems provokes common organization behaviors: “Our lots is due more to what we do then what is done to us”. [More]

Posted by: alissonvale
Posted on: 3/1/2013 at 11:07 AM
Tags:
Categories: Management
Actions: E-mail | Kick it! | DZone it! | del.icio.us
Post Information: Permalink | Comments (0) | Post RSSRSS comment feed
 
 
Introducing "retrospectives" for a new team that I'm working with: I ask: What problems did you have since last time I had been here? Result of discussion: 7 different problems listed on the board. What actions would we take to make them disappear from now on? They suggested 5 actions. I agree with all and suggest another 4. All of them were just small adjustments on process or behavior. So far: 9 actions listed on the board. I ask: - Good?- Good!  - Can you do it? - Sure. Easy! - Do you think we can check the effectiveness of these changes next month and discuss about new problems that will arrive until there? - Sure. - Do you think you can repeat this process every month even if I'm not here to lead? (silence) -> hmmm, understandable... change a habit is a different level of commitment! - Ok. Let's think this way: Try to establish a reality where you do this every month. How would be the work process 10 months from now? Better or much better? - Much better! - Nice! Now try to create a parallel dimension where you don't do this. We just work and work and work... no improvement process whatsoever. How would be the work process 10 months from now? The same, worse or much worse? - The same? - No! Much worse! - Why? - Feedback cycles. Systems, and work systems are not different from any regular system, are composed by feedback cycles. They are the way systems run themselves. When you don't improve over time you are in a self-reinforcing positive feedback loop. Problems increase the level of insatisfaction on team members. Displeased with how things are going, people care less about their work, which generates more problems, and by consequence, more insatisfaction. The cycle keeps reinforcing the level of insatisfaction and the work environment tends to get much worse. When you improve over time you are in a self-correcting negative feedback loop. Actions to improve restore and control the level of insatisfaction. Good results motivate people to keep improving and to care more about the work. This is also called "pursuit of excellence". Lesson: There is no stable work place. A work environment that doesn't improve, gets worst.

Posted by: alissonvale
Posted on: 2/18/2013 at 4:03 PM
Tags: , ,
Categories: Management | Projetos Ágeis
Actions: E-mail | Kick it! | DZone it! | del.icio.us
Post Information: Permalink | Comments (0) | Post RSSRSS comment feed
 
 
Last September I presented this topic in the 2012 Agile Brazil conference in Sao Paulo. The reception was great and finally I had the opportunity to translate it to english so it can be viewed by a larger audience. [More]

Posted by: alissonvale
Posted on: 10/29/2012 at 7:39 AM
Tags: , , , , ,
Categories: Conferences | Management | Projetos Ágeis
Actions: E-mail | Kick it! | DZone it! | del.icio.us
Post Information: Permalink | Comments (0) | Post RSSRSS comment feed
 
 
  Every work environment has a well defined “work model”. It is common to hear people saying things like “- there is no process at all here! We just do it.”. Even in these cases, where there isn't an explicit “process”, a work model can be extracted and used as starting point for improvement. Your work model is just the way you do the work at certain point. It is dynamic, because it evolves positively or negatively along time regardless your will. However, it evolves slowly most of the time allowing you to extract a physycal representation that can help you to see how it looks like at certain point, what are possible improvement points to persue and, mainly, what are your current options for taking action and delivery not only things right, but also the right things. Identify and understand your work model, visualize it and talk about it frequently is a great way to increase awareness of the game you are playing. Visualization enhances your hability to analyze your options and choose the one considering the whole context, not only your current pressures. A good way to stabilize your work model is to create a physical representation that make those options explicit. Physycal and electronic kanban boards are just perfect for this job. Another important aspect of work models stabilization is the establishment of a regular cadence of value delivery. This cadence is essential not only to make explicit your ability to reach your purpose regularly, but also to make explicit if you are getting better or worst in this game as time goes on. When we talk about cadence, we need to talk about time. Time is always the dominant parameter for knowledge work or creative work. The question is never “What should be done to reach the goal?” but always “How much time do I have to reach the goal?”. For this type of work, the iron triangle is obsolete. We commit to an objective and use the time we have to generate a scope whose purpose is to reach the goal. The scope is always output, never input. Frequency of value delivery (your process “heart beat”) is where you can evaluate the most important feedback loop of your work place. A known frequency of value delivery implies predictability and a predictable delivery process is an important indication of a healthy process. Every work process could be stabilized using these few concepts: visualize it, talk about it and persue cadence. Yes, it could be better by doing that, but you shouldn't do that only for the sake of just making it better, you should do it because you need to put your car on the right road. Few things are so wasteful as putting your car to move faster on the wrong road.

Posted by: alissonvale
Posted on: 10/14/2012 at 2:48 AM
Tags: , , , ,
Categories: Management | thoughts
Actions: E-mail | Kick it! | DZone it! | del.icio.us
Post Information: Permalink | Comments (0) | Post RSSRSS comment feed
 
 
Last May at the Lean SSC 2011 conference I introduced my thoughts to some colleagues about the interpretation of what I think would be one of the fundamental elements in knowledge work systems: cycles of evaluations of assumptions. Alan Shalloway has recently taken this conversation forward, connecting these thoughts to other ideas related to risk and flow on this blog post. So, I have decided to write about the topic in more detail so we can explore this in terms of understanding what I think is part of what the Lean-Kanban and Agile communities do and why it matters so much.   Why we should care about assumptions   Assumptions are at the heart of all knowledge work activities. In the software development field, you can find them everywhere, from coding to portfolio management, from the smaller technical decisions to larger product design decisions. The evaluation of an assumption ends the cycle of learning and defines the boundaries around systemic feedback loops. Several things happen when you evaluate one or a set of assumptions:    (1) Learning: The evaluation of an assumption holds a very important opportunity for learning. By comparing what you have with what you were expecting, you learn about what you are capable of. You learn to separate facts from intuition. You learn how to work with small expectations and how to quickly change bigger expectations as derivate smaller ones are being evaluated. (2) Making Progress Towards a Goal in a Terrain of Uncertainty: In knowledge-based environments all you have is uncertainty. You don't know how much time takes to do a task. You don't know how one task is going to affect others until all the assumptions around it are validated. So progress in those environments is not defined by putting another brick in the wall, but by a recurrent evaluation of assumptions that emerges as you move forward from one uncertainty to another.  (3) Establishing Relations of Causality/Correlation: This insight came from Don Reinertsen, when we were discussing the topic with other colleagues at LSSC11. In fact, as the time to evaluate your assumptions increases, the potential to rationalize the result in terms of causality or correlation will be reduced. These are fundamental mental capabilities to find opportunities to learn and improve.  (4) Reducing risk: Alan Shalloway was the first to relate this to the work of Bob Charette. By controlling the number of assumptions in a given system, you are actually shortening the range of options and probabilities of getting an unexpected result. I believe if you design mechanisms to control the volume of non-evaluated assumptions in a given system, you are creating the potential to mitigate certain types of risk without too much case by case upfront analysis.     The awareness of being surrounded by assumptions is a property of an environment tolerant to failure. As Alan Shalloway stated on the earlier mentioned post: “Sometimes we are so sure of our assumptions that when we prove them wrong, we call the action doing so an error”. Errors only happen when you have been proven wrong in conduct or judgement by actual facts. It is a mistake to encourage a culture of establishing guilty and comparing results with expectations when what you just have are assumptions. It is important to learn how to separate unexpected results operating on fact-based reality from unexpected results obtained from non-evaluated assumptions.   Time is the dominant parameter   Acknowledging the existence of assumptions in our knowledge work environments is the first step. However, just knowing the relevancy of this is not enough. We need to know “how” to use this awareness in order to design better work systems.   My breakthrough about the “how” came when I first read about John Boyd's work few months ago. His theory is centered on the OODA Loop concept (Observe, Orient, Decide, Act). According Boyd, every active entity, like an individual, a group of individuals or an organization, use the OODA loop to react to events. They first observe the environment or situation they are involved in, then they analyze the data applying it their own background of knowledge and experiences, taking a decision to finally act based on that information.   However, instead of concentrating on the quality aspect in each part of the loop, which cycles like PDCA and LAMBDA seem to describe well, Boyd came up with something really interesting. For Boyd, what mattered most is not how good you are at observing, orienting, deciding or acting, but how fast you go through these stages in order to start a new cycle. Despite most of his work being oriented to environments dominated by competition, I think this could be also applied to collaborative environments, when the fundamental principle is about adaptation and responsiveness to new information obtained from an environment in constant change.             As Boyd's theory suggests, the speed of iteration is more important than being right when iterating. If the evaluation of assumptions marks the boundary for feedback loops in knowledge work environments, maybe the same rule applies for how we iterate in our activities. In other words, being fast at evaluating our assumptions is better than trying to force assumptions to be right at the end. So, to be effective in knowledge work environments we need to constantly try to minimize the time between the creation or emergence of an assumption until its evaluation.   In order to represent that concept, I've came up with this expression which represents the whole idea in few symbols:   ? – min(t) → ! Where:  ? represents the creation of an assumption   !  represents the evaluation of that assumption  min(t) represents the focus on minimizing the time between the creation and evaluation of the assumption   How programmers are minimizing the time-life of assumptions   If you were a programmer in the mid-1980s you probably remember writing programs on punched cards. Look at how the wikipedia describes a punched card:   A punched card is a flexible write-once medium that encodes, most commonly, 80 characters of data. Groups or "decks" of cards form programs and collections of data. Users could create cards using a desk-sized keypunch with a typewriter-like keyboard. A typing error generally necessitated repunching an entire card. A single character typo could be corrected by duplicating the card up to the error column, typing the correct character and then duplicating the rest of the card. (...) These forms were then converted to cards by keypunch operators and, in some cases, checked by verifiers.   At that time, programmers had to write their code on these cards and then submit them to an operator who ran the program on IBM mainframe computers. It could take days to get the response from the execution of those programs! After days waiting for the response, the result could be something like: Error on line 32.   I started my own career as a software developer in the late 80's. Before being a real programmer, I used to type several pages of printed code in Brazilian magazines just to run them and realize - probably because of my own mistakes while typing the code – that the program didn't work. It could took several hours to copy the whole program line by line. The result of running the program could just be a blank screen or a small square blinking somewhere on the screen.      We all know that the practice of writing several lines of code before you can evaluate them is not as good as evaluating a few lines or even each line as you type.  We also know that the practice of writing a really simple test, that evaluates one single behavior of your code, is considered a better practice than writing complex tests with complicated scenarios and multiple inputs and outputs.  The point is not only about simplicity versus complexity, but also about the speed in which you can evaluate the whole set of assumptions that you carry when you write those lines.     Nowadays, compilers and interpreters are getting quicker at showing typos and syntax mistakes. In some software development platforms, compilation or interpretation of the code occurs in the background, and I have instantaneous feedback of my errors. If I'm using techniques like Test Driven Development (TDD) or Behavior Driven Development (BDD), I can also get instantaneous feedback not only if I mistype something, but also if the system is doing what it should. Ruby developers, for instance, have shrunk this feedback loop even more by having their tests automatically executed in the background for every saved change in their source files.  Developers have been applying intense assumption-oriented semantics to specify their behaviors. So you see words like “should” dominating their vocabulary, which is a clear indication of awareness of  the assumption inherent to each piece of code.    From punched cards and long lists of non-validated code to real time validation for syntax and purpose, what is common in all of those evolutionary leaps is the exponential growth in the ability to  reduce the time-life of assumptions in the form of non-validated lines of code. Every line of code carries its own assumptions. It assumes that it is written in the right syntax, that it is the right instruction, that it is in the right place and it is the best way to do what should be done at that point.    Peer Review   Programmers have to deal with several challenges when they are working together in teams. Style and syntax standards, code design, usability guidelines, test practices and other rules should be aligned among all developers in the same team. There are so many details and different situations when you are coding, that just write rules down and expect everyone to follow is not such a good option.    As software development becomes a repetitive activity, quality goes down. That happens because the code is a complex artifact. You need to embrace the inherent variability to prevent the uncontrolled expansion of that complexity. Documented “standards” don’t help to deal with that variability.   It is common to use a review cycle to help developers to align themselves in a common structured model. When a feature is completed by a developer, another developer must review what was done. He is supposed to point it out what doesn’t fit in the work structure of the team, what could be better and what could be removed because is not necessary. As time goes on, the expectation is the formation of a shared mental model that everyone follow by agreement, not by rules in a document.    The problem is that there are several ways to do this. One possible way involves one developer handing off the implemented feature to another. That is not a good solution in most cases. Besides the natural issues regarding handoffs, who are receiving the task probably will enqueue it until he finishes his current task. As usually there is no visibility or limits controlling what is happening, the volume of work waiting for review can increase very quickly.      Another way to make code reviews involves the practice of pulling someone to review the code together with the original developer as soon as the feature is implemented. This is a much better solution, once it eliminates the handoff, prevent the formation of queues and promote collaboration. However, it still carries downsides like interruption, context switching, hurry on finish the work and lack of involvement of the reviewer since the beginning.   We can think about different solutions for the review problem, but developers have discovered a much more efficient way to handle that, which is called pair programming. In this model, two developers work together during the whole time until the feature finishes. Every action or decision is immediately reviewed by the peer. There is no handoff, no context switching, no hurry, no lack of involvement anymore.   However, pair programming still let the space for some dysfunctions once the feature absorbs the mental model of only two people in the team. A technique called promiscuous pairing addresses this problem by making developers change position between each other in a certain frequency, so all of them can work a little in all features.   As was explained in the context of coding, here we have the same pattern of evolutionary leaps. When a developer starts coding, assumptions about this code are created. Is it following the style and rules used by the team? Is doing what was supposed to do? Is there some design issues or flaws that should be solved before finishing? These and other assumptions are living in the system until being evaluated by another team member. The review process is just another way to evaluate these assumptions. Again, the time is what matters. In the first review model, the handoff extends this time quite a lot. The second model, when a developer pulls another to do the review, the time of evaluation is reduced to the time for develop the feature, which is better. The pair programming model makes this time to be near zero, but it still maintains some assumptions in the system. By doing promiscuous pairing, your evaluation embraces more assumptions and the time remains minimal.          How the management system is affected by assumptions   Accumulation of assumptions is probably one of the biggest sources of dysfunction in value-add activities in knowledge work environments. It is not different when we analyze management activities.    The Agile Manifesto probably has marked the emergence of a new paradigm in the software development world. In terms of management, the Agile movement, and after that, the Lean-Kanban movement in software development, both promote a different approach. The predictable world of Command and Control was left behind, opening space to a new understanding focusing on people  over processes and collaboration over contract negotiations. Managers are now supposed to be system thinkers, instead of resource controllers. While this transformation was taking place, in terms of assumption evaluations, dramatic changes occurred.   When someone is doing a task for others, there are some implicit assumptions made during the whole process. Is the right direction being followed? It is being done correctly? Is that the right thing to do at the time? Many times we hear the same story. Weeks or months after a manager assign tasks to developers, usually in large batches, they discover that nothing works as expected, that the code has no quality, and developers are taking the blame and leaving the project.    Most managers would say that this happens because of lack of control, that managers should command and control tightly. But, should they? Should they try to impose predictability to a naturally unpredictable environment? I don’t think that is the answer. In those types of projects, as time goes on, new assumptions are in constant generation because you are essentially dealing with partial information all the time. As the project moves forward, you start to collect pieces of information that were lacking when you first started. Evaluating assumptions helps you to confirm or refute decisions that were created in the first place by the lack of that information. This applies not only for developers writing code, but for management practices as well.   Let’s analyze some management practices using this perspective. Nowadays, more and more developer teams are doing 15 minutes stand-up meetings on a daily basis. They do that to improve communication and alignment towards a shared goal. What they probably don’t know is that in every one of these meetings they are evaluating some important assumptions: that everybody on the team have been working in the right direction, that everybody is going to work in the right direction tomorrow and that the team know about the problems so members can help each other to overcome problematic situations. Do you agree if we evaluate these assumptions every week, instead of every day, we are just allowing the accumulation of some critical assumptions that could jeopardize our short-term goals? Those meetings are usually kept really simple, short and frequent, because the focus is not doing the meeting right, but do it frequent enough to not allow that assumption to live without validation for a long period of time.   Why short iterations?   Scrum practitioners have also been applying the concept of short evaluations in assumptions to dealing with estimations. They assign “points” (Story Points) to units of work. The amount of points for each unit increases as the complexity or uncertainty for what is expected of that work increases. The project is broken into timebox iterations. When an iteration starts, the team defines how many points each unit of work is worth and the total number of points they can handle for the whole iteration. What a lot of Scrum teams don’t realize is that this is just an assumption. The total amount of estimated points is an assumption of future throughput, not a commitment whatsoever. The number of points for each unit of work is also just an assumption of the understanding of the problem that has to be solved, not a commitment to fit the work to its estimation.   Now you probably can understand why short iterations are frequently better and why teams working this way are considered “more mature” than teams working with longer iterations. If you really want to know more about your capacity, then the time to evaluate the created assumption is crucial. Taking more time to do this evaluation ends up increasing the number of live assumptions in your system, making your knowledge about the capacity of the project less precise.     The Sprint Review is another Scrum ceremony which is useful on controlling assumptions in software projects. As the team is producing working software, non-evaluated assumptions about that work are being accumulated. Is each feature what the customer was expecting? As the development process starts, those assumptions come to life for every feature. Only when the feature is presented to the customer you can evaluate them. The Sprint Review marks the point where the evaluation happen. As the cadence of this ceremony is aligned with the time that an iteration get complete, shorter iterations will reduce the time-life of that assumption in projects running in a timebox fashion.    Continuous Deploy   After a feature is reviewed, another assumption appears: Does the new feature will need any adjustment to work well? The implemented feature needs to be deployed so the customer can actually use it. In order to publish a new release of the product, it is common to wait for a certain volume of new features sufficient to form a cohesive business operation. The average scale of this wait time is months. It is a quite large timeframe to keep non-validated assumptions alive.   The side effect of this delay is know as “release stabilization”.  Feedback from users comes in so large quantity right after the release being published that the team needs to stop the development of new features for weeks until have all these requests addressed. In other cases, it is not the volume of requests that bothers the team, but the lack of any request! Some features are released and nobody uses. The cost of added complexity to the code is really underestimated when this happens. Indeed, this happens a lot.   Some web companies with millions of users are showing the path to solve this problem. The time to reach the user is being minimized by a model which new features are progressively deployed for clusters of users in cycles of evaluation. So, a new feature is first deployed to a small group of users. The use of the feature is evaluated. If people don’t use it, the feature is simply killed. By other hand, if the new feature generates good feedback and attraction, they deploy it for the next group of users. Additionally, the first group points some flaws or misbehaviors in the product. This is corrected before the next group receives the feature. New analysis is made and feedback is collected, and the cycle goes on until all users get the feature.    Again, the main difference between the two models is that, on the second one, you recognize that what you did is based on assumptions. The users are the ones that are going to evaluate them, not the Product Owner or any other proxy role in your project. What makes you effective is how quick you can go to the customer to make this evaluation.   WIP Constraints   The emergence of the Kanban change management method brought new tools to deal with assumptions. Flow, Visibility and WIP constraints are in the essence of this approach. Those elements have a huge contribution in terms of reducing the time-life of assumptions.    Let’s go back to the customer review problem addressed by Scrum teams with the Sprint Review ceremony. We already know that teams working in short timebox iterations are  better in controlling the time-life of assumptions than teams working in longer iterations. But we can do better than that. What would happen if we create in our working system the ability to evaluate those assumptions as soon as you have the minimal conditions to do it, instead of doing in a pre-defined scheduled time?    With a WIP constraint you can control the accumulation of existent assumptions in the feature review process. The PO will be involved as soon as this accumulation reaches a desirable level. You can argue that more pressure on this cadence is not possible because of the PO availability or because any other reason. Fair enough. In this case, you can’t reduce the volume of assumptions in your system because you are subordinated to a constraint that you can’t remove. But don’t loose the opportunity to make your system better in controlling assumptions just because you want to stick to a method prescription. Scrum is a good set of practices, but are not the best set of practices, simply because, as the Cynefin Framework model suggests, in complex environments, there is no such thing as best practices. What exist are emergent practices. So, there is no reason to not design your process in a more efficient way.    Handoffs   WIP constraints have the potential to control the time-life of assumptions in several ways. A particular useful scenario is when you are dealing with handoffs. Despite being a necessary evil in some cases, handoffs should be avoided most of the times. When you transfer work between people, teams or organization units in a continuous way, you start very critical assumptions: Has the work arrived in a good condition? Who has received gets what was expecting? Who has to respond is going to do that in the expected timeframe? Is rework not going to be necessary? Is enough information about the work being passed with the work?    WIP constraints can minimize the impact of handoffs by forcing this assumptions to be evaluated before new ones are created. When everything is fine to move on, you are allowed to start new work. This practice has the potential to transform any knowledge work environment because, beside other reasons, you are controlling the amount of assumptions that are living in your work system in a given time. You do that by forcing their evaluation in a dramatic shorter cycle.    Visibility   Visibility is another Kanban element which has a systemic effect in assumptions. One fundamental aspect of work models is how much time is necessary for people react to new information that comes everyday. When the work model is visible, people on the team start to share a mental map where conditions and information about each important piece of work can be signalized.    In knowledge work, it is quite easy to see important information hidden in e-mail inboxes, phone calls or memos. If the work of everyone is projected on a single map, you move the assignment  model from a “per-individual-basis” to a “system-basis”. With a single map, people have a place to pull the work based on explicit policies and to discuss strategies to handle their challenges every day.     What visibility does is reveal one of the most important assumptions in knowledge work: that the system is working fine. When aligned with other Kanban principles, visibility empowers people to discuss a better distribution of efforts based on availability and importance, instead of just familiarity or personal assignment. They can anticipate and swarm in problems as soon they emerge.  They can work as a real team.   Customer Assumptions   As it was mentioned at the beginning of this text, you can observe a software development work system in terms of how it deals with the accumulation of assumptions over time.  This can be done by observing how people are dealing with their operational tasks, how managers are managing and how team practices can be organized to guarantee frequent evaluation of assumptions. But you can go further on this.   The recent Lean Startup movement is teaching us a valuable lesson. This community is learning how to minimize risk in creating the wrong product by evaluating assumptions about what customers really want during the development process. They use concepts such as Customer Driven-Development, Business Model Canvas and Minimum Viable Products to empower people with a effective method to do that.   The most common form of product development in the software development field involves the generation of a backlog of features. Then, you manage progress by comparing the planned features with the already developed features.  The problem with this approach is that it carries a large quantity of hidden assumptions about what the customer really need. A product can take years to be developed. After all this time, you discover that nobody wants to use it. Basically, because your focus remained on trying to meet scope, budget and schedule.   The Lean Startup community is learning to reduce the cycle of discovery of customer needs to a minimum time and effort. People now are launching product releases in really short cycles. They are reaching the customer even without a real product developed. They are doing this because they know that even the most brilliant idea is formed by a set of assumptions, and these assumptions need to be continuously evaluated before you do a major investment in the wrong product.   Basically what changes is the way you progress in your product development initiative. In this model, instead of moving from one feature to another, you move forward by evaluating one assumption after another. When you don’t have a positive response to your assumption, you pivot. The idea of pivoting makes the approach really strong. When you pivot, you use the new information that you have obtained to change the direction of the product making it compatible with the customer response. This is quite counter-intuitive because by deviating it from the original intention actually makes it stronger.     Here the same concept applies. It is the time and frequency of the evaluation that matters, not how perfect you do it.   Trade-off   There is a clear trade-off regarding how to find the optimal time to evaluate assumption for each feedback cycle.  It seems like value-add activities tend to offer space to near zero time, depending on the available tools or techniques.  However, coordination activities, like meetings, handoffs and reviews hold a transaction cost which makes the constant reduction of time not so useful.    As an example, standup meetings are a coordination activity which can be really effective on a weekly basis, a daily basis or even twice a day depending on the context. A team of managers can do that with project team leaders in a weekly basis. More than that will not generate any value because there aren’t enough assumptions accumulated on this period to be evaluated.  For a software development team, twice a day is too much, while for a maintenance team, living a period of crises, can do that twice a day easily.    However, in all those cases there is a optimal limit to reduce time between assumptions evaluation. The transaction cost of the activity helps us to define that limit. When you reach it, a good way to go further is stop thinking about how to reduce the time and think about how to replace the practice entirely. In this case, you act differently keeping the purpose of that practice in the context of the feedback cycle. The evolution from developers review to pair programming is a good example of this type of change. The purpose was sustained but the means was modified.    Takeaways   The evaluation of assumptions is a thinking tool. It can be used to analyze a system using a new perspective. It can be potentially useful for most knowledge workers, including developers,  managers, product designers and other IT specialists. Each one, in their own problem space, can use this tool not only to take better decisions, but also to improve the current know-how, designing the process to be more responsive and self-regulated.   If you are somehow involved in a Lean, Kanban or Agile initiative, stop for a while and try to think about the feedback loops that you have in your environment. When they are going to close? What assumptions are you carrying on at the moment? When they will be evaluated? What are the possible risks of letting non-validated assumptions accumulate in the system as time goes on?   Processes don’t evaluate assumptions, people do. Processes have feedback loops, but who close those loops are people. So when the Lean, Kanban or Agile communities tell you that “is all about the people”, pay attention to it. At the end is all about how your culture empower them to make good decisions, no matter what are their level of influence.  

Posted by: alissonvale
Posted on: 6/30/2011 at 3:18 AM
Tags: , , ,
Categories: Management | Projetos Ágeis
Actions: E-mail | Kick it! | DZone it! | del.icio.us
Post Information: Permalink | Comments (1) | Post RSSRSS comment feed
 
 
The snow ball effect: that is the metaphor that I was thinking about when I have prepared the talk "Making the Work Visible" for the Lean Software and System Conference occurred last week in Atlanta. The first idea turns around visualization as a catalyst for obtaining system understanding. To visualize an specific characteristic of your process, you need to think about it in a structured way, connecting this visualization to underline properties of your system. The exercise of doing that continuously generates understanding, which is what we are looking for at the end. On the other hand, something interesting happens when you raise your level of system understanding. New ideas emerge. The need to visualize different perspectives of the work appears. The snow ball effect takes place and a new focus on how the system is designed can be established. Three Design Focuses After a small history and introduction, I started to describe what became the three main focuses and discoveries we have when designing our system:#1 - Thinking in ecosystem rather than linear processesBy doing that, we amplified the directions we could follow to create understanding. We have connected different perceptions regarding the process. Themes like collaboration, personal involvement, engineering artifacts, coordination, achievements and others were considered once they are part of the whole ecosystem. Linear processes are still there, but not alone anymore.#2 - Contextualizing visual information rather than using traditional reportsInformation is part of the understanding process. You need information to get understanding. The usual way to get information is by querying your electronic data. While this is still a useful and important approach, when designing our system, we found valuable to connect the information about the work with the work itself. So, for instance, as you are seeing the current work in progress, you are also analyzing average wip allocation regarding the nature of work or the target market.#3 - Organizing the system considering interconnected perspectivesThis is probably the most important aspect of our design. Connecting different perspectives to model the environment help you to comprehend how things interact with each other. Visualizing the ecosystem in one direction enable you to create the necessary interconnections to see the system as a cohesive unit, amplifying your understanding about the whole. Here is our model based on perspectives: Figure 1: The system organized in perspectives The system visualization expand itself from the employee to the customer, revealing several perspectives in the middle: A personal perspective offers perception of involvement for each employee that participates on the system; A team perspective gathers individual contribution around common goals and results; A systemic perspective offers an end-to-end visualization of flow, besides information to handle the work as a whole in different systemic situations like demand, in progress and releasing. A customer perspective allows you to extract the flow of work related to specific client or market targets which aggregates several clients. Filtering Perspectives Some perspectives are orthogonal to the main perspectives described earlier. They represent an specific filter applied to the whole system, so you can isolate the work with different characteristics, like the market target, for example, or the continuous improvement actions, as I have demonstrated on the presentation. We can expand that to isolate whatever characteristic of the system we think relevant to isolate. The main point here is that you can see the whole with an specific and meaningfull filter applied to it. Figure 2: Orthogonal filtering based on meaningful properties of the work Making things visible You can make more things than you can imagine visible. Even abstract concepts like collaboration can be materialized if you have records of current/recent interactions between people doing the work. In essence I've presented 7 (seven) different dimmensions of visibility. Each one of them somehow connected to the main perspectives and affected by orthogonal filtering as well. Here they are: the nature of the work; the workflow; collaboration; time; information; engineering traceability; movements; On the following slides you can get some clues about how all these dimensions are make explicit. Making the Work Visible View more presentations from alissonvale However, a more precise perception will come when you watch our electronic environment visualization in action, which are not available in the slides. As the presentation was recorded in video by the InfoQ portal and also in a desktop recording tool, we can wait for the release of these media to get the full picture about what is behind all these concepts. While this not happen, I let you some screen shots to help you on visualizing what I meant by "Making the Work Visible". perspective of an individual team perspective system perspective customer perspective time perspective system performance perspective card swarming view business activities expanded WIP A big "Thank You" for the kind audience in Atlanta and also for the several good feedbacks that I had after the presentation.

Posted by: alissonvale
Posted on: 4/25/2010 at 1:59 PM
Tags: , ,
Categories: Conferences | Management
Actions: E-mail | Kick it! | DZone it! | del.icio.us
Post Information: Permalink | Comments (2) | Post RSSRSS comment feed
 
 
I always looked at risk management activities using the event-driven risk approach offered by the current project management traditions.Perhaps because of this, I've never paid so much attention on this topic before, as I am doing now. Flying back to Brazil from the conference in Miami, I had the opportunity to read the amazing piece of text that David Anderson wrote about Risk Management on the proceeding book of the conference. After that, I've started to think about risks in a different dimension. Now, I’m diving on this conclusion:Mutual Trust Relationships can be sustained by intrinsic risk management mechanisms.There is definitely something more in dealing with risks than just trying to create mitigation and contingency plans up-front.  To be relevant, risk management has to be merged into the system to orchestrate his behavior.I have this feeling today that any decision point in a process should be oriented by some risk analysis approach. I’m not talking about a plan for risk mitigation here; I’m talking about a process for continuous risk mitigation. Is that possible?In David's article, he describes a technique that uses Classes of Service (CoS) as an instrument to make the system works oriented to risk decisions according Cost of Delay. So, before you inject new work into the system you are conditioned to think about risks, once you have to classify each work item by doing an analysis of the associated Cost of Delay. The type of risk is going to influence behavior by the application of different contextual policies. Pure System Thinking!Labeling work items is a interesting mechanism to influence system behavior. If you use an e-mail system like Gmail you can see that in practice. When you decide to tag messages by some form of classification, you define a visual agreement mechanism that is able to influence your behavior. You are going to act differently when you see a message with a special tag type. What David is proposing is labeling work items by risk criteria, which is going to subordinate the system to be risk-oriented, a fundamental part of self-sustainable processes. So that's why David's article got my attention in the conference book. Explicit Risk Management is missing in our process. We have to figure it out how to apply this knowledge on it. In our process, we have a different use for Classes of Services.Instead of thinking about the risk, we are thinking about Value mapped to agreements that we need to respect as we interact with our customers. We talk to them in these terms:“You (the customer) should trust us (the vendor) as we will try very hard to keep your business up and running by solving any problem (1) that you have or by helping you in any operation (2) that you need assistance from us; we also are going to sustain your processes by doing improvements and adaptations (3) as your business evolve and, while we do that, we are constantly trying to deliver new features and capabilities in our software to create new business opportunities (4) that generates value for you in your market share.” This “Agreement Statement” maps to our Classes of Services (CoS):1 - Problem solving2 - Support and Operations3 - Improvements for sustainability4 - New ValueThe intention of our "Agreement Statement" is to create a Mutual Trust Relationship with them by being flexible with their needs and getting flexibility from them for our needs (which are mainly estimation, prioritization, error tolerance, and others). So, all units of work derived from this CoS have Value for the customer. But the lack of any of this agreement can make the long term relationship that we aim becomes unstable.We need to create balance by delivering units of work observing the system against this "Agreement Statement". During this observation we have to consider each individual customer and the whole system to make right decisions.We have an assumption here which is based on the fact that we have different entities of our system competing by the same (and limited) resource. So they have to trust us that we are going to take the best decision considering this "invisible" competition that is happening in background. This decision process is all about "risk analysis.” So, Risk Management is an important activity to create effectiveness on this decision process. An effective decision process creates trust, and high levels of efficiency on risk control leads to high levels of trust on this relationship.Using CoS as David suggests seems to be a quite reasonable approach, once CoS is the primary way to classify units of work in Kanban Systems. But, I’ve realized an underlying model for managing risks here, which are leading us to the definition of a new orthogonal ax in our system for risk-oriented work items classification and also for risk-oriented policies. Merging risk analysis into our system to influence its behaviors is going to be my next challenge for now. 

Posted by: alisson.vale
Posted on: 5/12/2009 at 4:58 PM
Tags: , ,
Categories: Management
Actions: E-mail | Kick it! | DZone it! | del.icio.us
Post Information: Permalink | Comments (2) | Post RSSRSS comment feed
 
 
 One of the central elements of Kanban is the ability that you acquire in redesigning continuously your process as you understand how things work in your scenario. In fact, understanding what we do was the first benefit that we got after starting to work with this approach about a year ago. Insofar as we have got this comprehension, we realize that there was something special about how we have been signalizing the elements of our process. As these signals become more meaningful, more stable and predictable becomes our process.Figure 1 shows what we call "The System View". That is the main view of the process and it is the most frequently used view by all team members.   Figure 1: View of the System as a Whole (Click to Expand) As you can see in Figure 1, there is a lot of signalization on our Kanban board. The signs help us to quickly answer some specific questions that we have to deal with on a daily basis, like "What am I supposed to do now?","What and How much has been delivered week after week?" or "What are in the system right now?". Besides, it helps us to make work go downstream more smoothly, sometimes by point us to flow decisions based on our politics and preferences, sometimes by showing up bottlenecks that happen from time to time.  The System itself is the first SignalizationOur Kanban board is organized in three main areas that suggest a systemic view of the process: Input, In Progress, Output. Our system was intentionally drawn using a systemic perspective. Like every other work system, we have a lot to do (Input), we are doing some work now (In Progress) and we had already delivered some work to our customers (Output). When you are looking to the Demand Area (Input), actually you are trying to look at the future. The WIP area represents the present and the delivered area the past. Look at this picture as a whole help us to make decisions when we see ourselves in front of hard situations involving priorization, capacity, overloading, flow, value and waste reduction. It is a key point of this approach the ability to evaluate specific situations having the whole picture in mind. Every decision results in the movement of a physical token that moves around the board following physical constraints and rules (like in a chessboard). The tokens are moved from the left to the right. I just can move a token to an empty space, for example. If there's no empty space, I have to create this space by moving other tokens to other areas. Then a trigger is fired to re-analyze the system in concern to priorization, schedule negotiation and resource availability.  In other words, when you (as a Team Member) are operating the system, you are using the signals to guide yourself. Just like in a chess game.  Figure 2: Signalization guides the Flow and Team Decisions Our board today can be seen with different eyes, or different views. We look at our system like we look at a map, and there are areas in this map that can be zoomed in to increase the details about what is happening in there. Figure 3 shows the three main areas in zoom. We need to look with more details to manage different areas of the system. Demand management, for example, is done by increasing the details of the Input Area. So when we have to organize the demand, some tools and visualization fit better with the nature of operations inherent to this area of the system: bigger cards, priorization filters, drag and drop of the cards between areas and slots, grouping by customer importance, and a basket thrash to put away old demands that expire as the time goes on. Figure 3: Expanding the Input Area with the Front View Another area where it is very important to take a closer look frequently is the WIP area (Figure 4). When we look at this area, we want to know how the things are going on now, in the present. Here we are monitoring other aspects of the process, for example:   Figure 4: WIP View   how the demand is distributed in terms of classification (see "Value and Demand" later on this article). To do that, we have a graphic signalization that shows the percentage of every class of service that we are working on in a moment. It allows us to influence the system in a way that more work of certain type can be injected to balance the output results. For example, we can prioritize more "value" work, when we see that the percentage of "non-value" work is too high.  how the demand is distributed for each team member. Sometimes the flow in the system is threatened by work accumulated in the buffers of team members. We can see that simply analyzing the amount of cards by work-state (See Figure 5). It also shows important information about team overloading and multi-tasking levels.   Figure 5: Amount of cards by work-state in WIP   don't loose the focus in cards that are "Waiting for Customer". This queue holds cards that are waiting for information or for deliberations from the customers. As more time they stay in this queue, worst will be for the flow of the system in a general way.  Parking Lots keep our eyes on the progress of deliverables that need several other minor deliveries to getting done. It could be a MMF (Minimum Marketable Feature) for example, when you need to group Value as a set of features or user stories to deliver at a once. They can also represent any other Business Activity that has to be done by the synchronized execution of several other cards, whatever class of service they are. The Delivery Area is what we see when the Output part of the system is zoomed in (Figure 6). This area represents the past, and is the source of our "Yesterday Weather" analysis for planning. Cycle time and other information are used to give us the necessary understanding about what we are capable of (in terms of delivering per class of service).  Figure 6: Delivery View Value and DemandAnother important topic that worth mentioning is how the work can be classified, sized and organized in the system. And the signalization comes again to help. We represent each unit of work in our system as a "Kanban Card" and we use different types of signalization to draw and organize them on the board (Figure 7):  Figure 7: Signalization of our unit of work (Kanban cards)  Each card is labelled with a unique number which help us to track it and to get a better communication when the team needs to talk about it. Bigger cards are used to represent the work before they enter in WIP (Work In Process), smaller ones after. The reason is because we can show the description of the work when they are bigger. It help us to analyze several of them at the same time when doing priorization.  Colors are used to classify the work by classes of service: [Green] for Value demand: features that generates new business opportunities for customers; [Yellow] for Improvements to Sustaining: features that customers are missing when trying to use the product to sustain their business; [Orange] for Support Operations: Activities to support the use of the product by customers; [Red] for Problem Solving: When a customer can not use the product appropriately for any reason;    In Lean terms the Green cards are value, and all the others are pure waste. Two types of borders indicate if the card is a unit of work for a customer (solid border) or for the own team tooling and process improvement (dashed border).   A sign in the top right area of the card indicates the estimated size of the work. We work with just three types of size: Small (it is our reference and it takes between 1 or 2 days of work to be done), Medium (3 times more complex than the reference) and Large (5 times more complex than the reference). The same colors are used to signalize how much of each class of service is in the three areas of the system. It can be a good measurement for tracking waste levels, or to help in controlling how much work of each type could enter in it. The interesting thing about this kind of signalization is to create opportunities to see the whole using the Lean perspective of Value. We can monitor how much effort of our system is consumed to generate value in a certain period of time for each class of service, and that is the main metric that we use to evaluate our process: how much money we are spending generating new value or dealing with waste?Stages, Queues and LimitsOnce we have our value and demand classified appropriately, it is important to see how this demand flows when it enters in the system. Our visual board contains areas representing each stage of the process. Most of this stages has limits to prevent new cards from entering in it. The limits cause some interesting systemic behaviours: they avoid the perpetual accumulation of work in stages where the rate of incoming is higher than the outgoing rate; they highlight the need for sequentialization inside the stage and constant priorization of the work; and they help in making a downstream operation to be the one that establishes the rhythm of the flow. Our stages and their signalization are shortly explained on Table 1.     The Front Queue  All the collected demand that are not qualified yet to get in the system regarding business criterias. The items of this queue are not important for who is looking at the System View. Just for those who are managing demand. But it is important to monitor the number of items in this situation for each project.    Waiting For LRM Queue  With a limit of 14. Items on this queue require more constant observation. They are just waiting a moviment in LRM Queue. This will create an empty space triggering another priorization action. So the work item is pulled from this Queue to the LRM Queue. When this happens, an empty space shows up in this one, which forces another priorization action. This time pulling another card from the Front Queue. That is the point in a Pull System. The next stage on the pipeline pulls the work as needed.   LRM Queue LRM is an acronym "Last Responsible Moment" and indicates that the best time to work on an item has coming. The first item of this queue is the one that will be pulled from the Team to start working on it. We have two LRM queues, one for each work cell (development and support operations). Look at the empty space on the first slot in the queue beside. That is the sign from the system that more work can be pulled from the front area.    Team Members WIP Queues Each Team Member (including the Leaders) organizes his demand using the work state of the item. Ideally, a team member would be holding just one card, and that one should stay on "In Progress" Area. But, in the real world we have to be able to deal with other cards in different state contexts. The Feedback area holds cards that come back from downstream, for quality reasons, for improvements or even for failing in following standard compliance policies. The Inspection area is filled by automatic distribution. The numbers in this area represent the order that which each team member will receive the next item for doing inspection. It means when someone moves a card indicating that it is "Done", this card is automatically associated to an another Team Member that has the number #1 in his slot. Then everyone else gets a new number (for example, the number #2 becomes the new number #1 and so on). This mechanism was created to randomize the allocation process for inspections and allows all team members to inspect the work of all the others members. This is an interesting way to influence the flow of the system using signalization.  Release Ready Queue When the work is done and inspected, the next stage indicates that the item is just ready for release. It means that the customer can already be notified about that job. Here we have different actions depending on the type of work or deploy issues. The notification can be just a link to download a new release of the product, or some instructions to configure the product or even just an information that some situation has been addressed and the product is ready to use.   Waiting For Customer Eventually, the work can't be done because some information or consideration from the customer. So this is a kind of "hospital" area, where the work stays stationary until we get the information and can proceed in WIP.   Released Queue That is the real output of the system. After we send the notification, we move the card to the release area, and the stop button of the cycle time clock is pressed.    Table 1: Stages of our Kanban System  "Stop the Line" SignalizationOne of the problems in visualizing a process as just a sequence of linear steps is underestimate those 20% of the situations that causes 80% of the problems. The linearity occurs just when you are observing in a high level view. On a daily basis, a lot of situations are happening and we have to be conscious about the complexity in handling multiple demands with different people and with different customer expectations at the same time. Implementing Autonomation can be powerful to avoid work without quality to move on through the process. A big source of quality problems generated by complex trade-offs when the work is in progress can be avoided. Just put your tools to send you some signs when possible anomalies are in place.     As an example, we have a sign that appears on our board when we get suspicious about the quality of a build generated by some modification in the product. This is quite different than the Continuous Integration sign (that we also use to check several aspects of the code base). A new release of the product will be only inspected after a successful CI build. If some quality issue is found during the inspection process, the kanban card will be moved to the feedback area of the team member who first implemented the modification. Meanwhile, if we have any new build (even from a different team member) that has just been moved to the release ready area, sharing the same code branch of the suspicious one, the board will signalize the problem as you can see in figures that show the release ready queue.The lesson here is that any process is rich in opportunities to fail. The idea is just get these signs and just "stop the line" until the team becomes confident again to continue the flow.Signalizing Kanban MovementsWhen you have a system where the kanban movements are quite frequent, with a lot of movements on the board daily, the ability to follow this movements becomes very important. It is also common that two or three team members are somehow collaborating to deliver the same unit of work. So a mechanism to let the Team know about the life cycle of the card as it is flowing through the system is necessary. The mechanism that we have been using to keep the team up-to-date is a system task bar notification tool (see Figure 8). Clicking on the notification window will send you directly to the details of the kanban card (Figure 9).  Figure 8: Signalization of a Kanban card movement Signs of CollaborationOne of the ways to see if your team is collaborating to get the things done is observing how they communicate with each other. Is the communication rich? Is it happens all the time or just when they meet each other on the stand-up meetings? Is there a way to look for signs of collaboration as the time goes on? We get these signs from our kanban system as well. We did that transforming our kanban cards in free spaces for open conversation. Everyone is stimulated to write short notes of anything related to that work on the card (see Figure 9).   Figure 9: Kanban card detail Every time someone attaches a note to a kanban card, the team receives the signalization with another task bar notification:  Figure 10: Signalization of a new note added to a kanban card  So we use the kanban as a key element to connect the process of management to the process of communication. That became a huge element of leverage in our collaboration model.Signs can point you to Technical ArtifactsIn software development, management and technical activities are closely related. It is not simple to get traceability from management to code. But when you got it, your process become more reliable and a lot of facilities comes to help. In the output area of the System View you can notice that some kanban cards have a build number near it. It means that we had to generate a new build for the application to deliver the associated demand.   This kind of sign combined with the type of demand show us how many changes we are doing in the software to solve bugs or to create features for sustaining without creating new value. It is just another sign that brings the waste to the surface, making the team conscious about the pain of technical debt. To do that, our build server was configured to update the kanban card with the build number when a new build pass by the Continuous Integration process. That kind of automation is just possible because we enforce a commit policy on our subversion repository where the developer has to inform what kanban card is associated with the changes in the code base. With this kind of policy we can go from the demand to any other important technical artifact, including how the code base was changed to attend it (see Figure 11). Figure 11: Traceability from the customer demand to technical artifacts Final Words about Signs    Signs are good mechanism of compensation when you are trying to influence a system. To correct something that is not working appropriately, you first have to see a sign of it. Usually signs of deviations from the expected behaviour come very late. The kanban management technique is great to make these signs visible all the time. We are still looking for good ways to find these signs and improve our process. 

Posted by: alisson.vale
Posted on: 2/22/2009 at 11:11 AM
Tags:
Categories: Management | Projetos Ágeis
Actions: E-mail | Kick it! | DZone it! | del.icio.us
Post Information: Permalink | Comments (2) | Post RSSRSS comment feed
 
 
Have you ever thought about using twitter to improve communication with your team?I have been tweeting since early this month and definetely couldn't stop anymore.You can follow me here: http://twitter.com/alissonvaleWhen I realized the great concept behind the tool (quick, open and uncomprimising communication), I decided to put our team to try it.The results after some weeks was awesome. Now we use the tool intesively all day long.The ability to broadcast information througth the team is powerful. You can use to simple messages like "The server x was updated.",  to give advices for co-workers like "be carefull with Visual Studio when you do this", announcements, or to talk about a new solution to some daily operation that you wish to automate somehow.I really recommend for other teams to improve communication. 

Posted by: alisson.vale
Posted on: 2/21/2009 at 7:58 AM
Tags: ,
Categories: Management
Actions: E-mail | Kick it! | DZone it! | del.icio.us
Post Information: Permalink | Comments (0) | Post RSSRSS comment feed
 
 
What strategies, principles, and methods can be leveraged to optimally match supply and demand over time? [More]

Posted by: alisson.vale
Posted on: 2/8/2009 at 1:43 PM
Tags: ,
Categories: Management
Actions: E-mail | Kick it! | DZone it! | del.icio.us
Post Information: Permalink | Comments (0) | Post RSSRSS comment feed