Berteig Consulting Inc. is offering a ScrumMaster Certification course on Dec. 28 and 29 in Toronto, ON. This course is focused on software and IT projects, but will cover many of the basic Agile Work principles and practices. This is always a slow time at work and if you have already used your vacation time, consider getting your employer to send you to this course.
First, a link: Retrospectives.com. From the site, the Retrospective Prime Directive:
Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
Today I assisted a fellow-coach, Deborah Hartmann with a retrospective for a team that she is coaching. Deb is actually coaching two teams in a program and couldn’t be with them both at the same time. She introduced me to a very simple yet pleasant and effective method for retrospectives. I am not sure of its ultimate source, but it was introduced to Deb by Michael Spayd. Here is the basic outline:
Materials: pad of largish PostIt notes, large pad of poster-size paper, marker, pens for everyone
Set up in a space where everyone can see each other and the poster pad.
Step One: get everyone’s attention, organize around the table, turn off laptops, put cell phones on buzz, and state ground rules: no interrupting each other, and that this is not a discussion until you (the facilitator) say so
Step Two: display and recite the cardinal rule (above) and the purpose of the retrospective
Step Three: What Went Well?
– everyone takes three PostIts
– write down on the PostIts what went well (technical, team, organizational, process, general or specific)
– facilitator puts them on the poster in a way that they are not visible to the group
– facilitator reads them all out in random order with no comments
– facilitator gets the group to brainstorm (no criticism) on themes of what went well and writes them down for all to see
Step Four: What Needs Improvement?
– repeat Step Three
– vote on the importance of the themes and chose the three most important to discuss
– facilitate discussion to generate action items for making improvements based on the three most important themes
I just found a very interesting presentation about using Agile Work to do planning for programs for people with disabilities. I didn’t understand everything in the presentation because the field is something that I am not familiar with, but it appears that someone has taken Agile from IT and applied it to social and economic development programs for disabled people.
Queueing theory describes the statistical and theoretical behavior of queues. In a queue system, there are two basic parts: work items and worker units. Worker units perform some work upon work items. The streaming of work items through worker units composes a queueing system. The time it takes for a work item to enter the system to exit the system is the process cycle time. From the study of real queueing systems and from simulation of queueing systems, researchers have shown there are some simple methods for creating an efficient queueing system that minimizes process cycle time.
One method for making a queueing system more efficient relates to the size of work items and how this relates to worker unit utilization levels and process cycle time. Queues behave in a very interesting way in relation to utilization and process cycle time. As utilization of a worker unit approaches 100%, process cycle time goes up very quickly. Not only that, but the more variability there is in the size of the work items, the worse this effect becomes. With a queue with work items that are all the same size, the worker units can maintain a very high level of utilization and the process cycle time is not significantly affected. However, with a queue with work items that are many different sizes, a worker unit will slow down significantly and process cycle times become worse even with relatively low levels of utilization.
Lean and Agile both use these ideas. Lean applies these ideas to manufacturing and other production processes and Agile applies these ideas to project work.
In Agile, iterations are used to create consistently small sized units of work that are then taken on by a team. In other words, the work items are designed to be exactly the size of an iteration and the worker unit is the Agile team. Since iterations are typically much smaller than the size of the overall project and since each iteration is always the same size, this allows the team to achieve very high levels of utilization while maintaining extremely short cycle times (the length of the iteration or release). Compare this to the waterfall approach to project management where the work is only finally delivered at the very end of a long process and you can see that not only do you have a very long cycle time, but each project will be highly variable in size and therefore it will be hard to get good utilization out of teams (think resource planning and leveling).
The Theory of Constraints, which is nicely introduced in The Goal by Eli Goldratt, presents some additional basic techniques for making improvements in efficiency of a process. The basic idea is that one can always find a slowest point or constraint in a process by finding out where there is a buildup of unfinished work. For example, if two people are cleaning a kitchen, one washing dishes and the other drying, if the number of wet washed dishes keeps building up, then the constraint for the process is the person drying. In more complex processes either in manufacturing or in creative work such as software development, it is sometimes more difficult to see where the constraint is. Typically, if you find that you have people waiting for work that is coming from someone else, then that someone else is a constraint and means can be found to improve their efficiency. In Agile, the focus on resolving the constraint would be to provide that person extra training or get other members of the team to assist in the work. Agile tends to shy away from a mechanistic perspective on efficiency.
Finally, in any queueing system there is some point at which work enters the system. This point of entry is very important because it can be used to control the utilization levels of worker units in a queue. In Agile Work, this control is accomplished through backlog management, iterative delivery and adaptive planning. All possible requests, features, constraints, improvements for a project are put into a master Work Item List. This list is strictly prioritized in descending order by a person empowered with this responsibility (called the Product Owner). This list of work items becomes the basis for deciding what work the team will do each iteration. The process of managing this list and how the work is chosen for this iteration allows the customer/client to prioritize important things to be delivered quickly and allows the team to work on consistently sized work units (iterations) and therefore achieve very high levels of utilization. In queueing theory this process is referred to as the gating function in that it provides a gate that lets work items into the system. All work must go through this gate or work item list management process in order for the team to function effectively. If the team is interrupted with work that has somehow skipped the gate it will seriously reduce the efficiency of the team(e.g. a senior sales person comes to the team and declares that it must work on X, it’ll only take a day, a potential client really needs this, surely that won’t hurt?).
John Brothers is hosting the Carnival of the Agilists. There are some very interesting news items and views – please check it out and spread the word.
A fellow agile coach pointed me to this great little article about burndown/up charts. It has some nice drawings of alternatives to the basic simple burndown that most teams start with.
These alternative forms of burndown attempt to provide more information about the status and history of an iteration basically by providing a means to update the “baseline” estimates. The advantage of doing this is that it allows for easier discussion of when and why new work was discovered. As well, it maintains the existing advantage of a burndown with its clear focus on getting to done by the end of the iteration.
I coached a long-running program with at times up to 8 teams, 6 of which were running as agile teams. We used a program-level status meeting daily to do “official” coordination among teams.
Early on in the program, one of the team members who was maintaining the backlog for the iteration came to me and told me that Team 4 was done their work ahead of the end of the iteration and Team 3 was struggling to get their work done in the iteration. As the Process Facilitator I got this person plus members of the two teams together to have a quick 2 minute disucussion about the problem (T4 running out of work). They quickly worked it out amongst themselves and then let the other team member know so that he could maintain the backlog by redistributing the work items and tasks. The two teams easily fixed the problem and the iteration ended successfully.
If you have worked in a highly bureaucratic environment you will know that it can be extremely difficult to adjust plans to allow this sort of on-the-fly rebalancing of work. In chaotic environments, on the other hand, it is just too difficult to see these sorts of opportunities for rebalancing in the face of constant crisis and “heroic” efforts by people on the teams. Agile Work and the process facilitator provide a balanced context in which this adaptability and self-organization can flourish.
Mishkin Berteig, the founder of Berteig Consulting Inc. and a principal contributor to the Agile Advice blog has been listed on the Control Chaos web site as a Certified ScrumMaster Trainer. This certification represents acknowledgement of Mishkin’s ability to deliver the ScrumMaster certification course. Scrum is a collection of management patterns used to implement agile principles and practices for software new product development.
Steve L. Robins, Professor and Diversity Trainer speaks about Unintentional Intelligence:
M1 (mindlessness) + M2 (multiple redundancy messages) = UI (unintentional Intelligence)
He explains that cognitively we can only do one thing at a time. Our brain writes cognitive scripts for what we do, so we can be efficient by not having to spend time thinking carefully about everything. We do this for anything from breathing, brushing our teeth and driving. We have very good cognitive scripts for complex tasks.
M2 (multiple redundancy messages
Because of this state of mindlessness, if we get the same message over and over again we have no defense against it. We can brand products, concepts, professions (i.e. a nurse is a woman a doctor is a man)… we brand people, race. We can get 13 year old girls to want to kill themselves because they are not thin enough.
Robins did the following experiment with us to demonstrate this point: He told us to repeat the word â€œtopâ€ ten times and after the tenth time he asked us the following question, which we were supposed to answer without thinking: â€œWhat do you do when you get to a green light?â€ We all said stop. He went on to point out that if with such a simple exercise he could get us to give the wrong answer, when we all knew the right answer, then a lot of different kind of beliefs about different races can also affect us even if they are not true.
Robins went on to talk about how to change these pattern: Neurons in the brain are connected by synapses, every time we act the body releases a protein in the synapses that when repeated solidifies the pattern down in our brain. In order to form new patterns a person has to have a chance to practice that pattern over and over again.
In our working cultures we have all kinds of cognitive scripts related to how we see and value diversity and these are formed partly by the multiple redundancy messages sent to us by our culture, our own lack of knowledge and experience of different perspectives and ways of seeing the world (because we tend to naturally associate with people who are like us) and our organizational culture that generally tends to value a certain kind of personality over another.
So what does this have to do with Agile? Well, so much of agile is about innovation and amplifying learning. Corporate cultures are not typically examples of thriving places that value diversity (and I don’t mean just having affirmative action programs, but beyond that, having a working culture that allows people to bring their diversity into the work place and rewards it). Diversity is a direct challenge to our mindless orientation towards work. It can challenge us to be more mindful, and mindfulness is an important basis of amplifying learning and being innovative.
I find the concept of cognitive scripts a helpful one for my own approach to Agile Work. Part of the work of a Process Facilitator is to help people to become conscious of their cognitive scrips, nurture diversity in the group so that cognitive scripts can be challenged to give birth to innovation. The key to this kind of change is for the Process Facilitator to work closely with team members to create repeated opportunities for this kind of interaction so that new cognitive scripts can be written.
It is helpful for the Process Facilitator to work with team members to reflect on the relationship between multiple redundancy messages as they relate to Agile Work. For example when starting an Agile project, beginning by reflecting on the fact that Agile Work transforms our competitive orientation towards work into a collaborative orientation. An examination of the multiple redundancy messages we receive in popular culture and corporate culture about these two orientations may be very useful for team members to become conscious of, if they are to make this shift in thinking and practice. As an exercise, a Process Facilitator could simply ask the team to list examples of corporate and media messages that support competition and those that support collaboration.