PDOS Archives

PDOS Page 3

In recent posts we talked about teams. We noted how the time box product development system produces two teams, both of which are authentic and appropriate for the execution of product development work. Ultimately what we’re interested in is productivity. So let’s look at this in the context of productivity. The two teams within the time box system are the Leadership Team and the Development/Execution Team. In today’s video we’ll be talking about the leadership team.

As noted in a previous video this team operates like a tennis doubles team. They each have their own assignment but they share work and responsibility; they cover for each other. One member of the team is focused on workflow; on making sure the work flows through the time box efficiently. The other focuses on ensuring the work being executed in the time box is the work of highest value and highest priority. If you create great value with great efficiency you have high productivity.

The efficiency of the time box system managed by this pair is also enhanced by two other elements. One is the filtering of requests into the time box. They make sure it is crystal clear what is being requested of the team. They make sure there is no efficiency lost by team members having to figure out or research what is being requested when it arrives at their desk. The other is the loading of the time box itself in which this team loads an amount of work that is accurately matched to the capacity of that team during that time box period. This eliminates the inefficiencies that are inherent in the overburdened standard matrix approach to the execution of product development.

So we have great efficiency coupled with a focus on the work of highest value. This pair of great value and efficiency is definitely high productivity. The tennis pair’s leadership team in the time box system leads to high productivity. So, that’s one team. In the next post we’ll look at the other team that contributes to high productivity within the time box system.

Contact us to learn more about how Systems Thinking and the application of our Product Development Operating System can help your organization become more efficient, productive, innovative, and competitive.

Follow Bill at http://www.twitter.com/systhinking

In the last post we talked about resource deployment and how we take individuals in product development and assign them to maybe 5 or more project teams. In fragmenting people this way we undercut their morale and efficiency. A preferable way would be to keep people intact. Assign them to one specific team and have them operate on that team, collaboratively with the other product development team members. A way of doing this is through Timeboxing.

Timeboxing is the translation of Agile Software Development into the Hardware or Systems domain. In timeboxing the individuals assigned to a time box, the engineers and other SME’s, are kept intact while the work that is loaded into the time box is sub-divided and fragmented. A great benefit of this is that, as the work is fragmented, it’s done so through dialogue. This dialogue builds a collaborative spirit amongst the team and creates in them a shared vision of the work that needs to be done and how they’ll go about executing the work.

In a time box you take a series of projects and break the work on these projects into smaller pieces and into the time box for execution. These projects can be prioritized so you’re not only optimizing the workflow, the capacity against the available resources to do the work, but you’re always working on the most important projects over any period of time.

Aside from those benefits there’s also the benefits at the human level. Benefits like the affiliation with a team; an accord that develops between these whole individuals as members of the time box team. You have this dialogue during the period of decimating and grooming the work, which leads to a shared vision of the work. You also have an unexpected benefit in the quality mindset of the team. Rather than degrading to a least common denominator, regression to mean of quality consciousness, the quality leaders of the team actually elevate the quality mindset of the team.

In the next session we’re going to talk some more about the team and the team structure inside of timeboxing, but the key takeaway from today is this — if you can keep an individual whole and tie them to a team, there’s incredible benefits both for morale and efficiency of the organization.

Follow Bill at http://www.twitter.com/systhinking

Teams have great value. They have value for the individual who participates in a team – the value of affiliation and the motivation from participating in something bigger than themselves. There is also value to the company. There’s a very strong correlation between team participation and product quality.

When we form teams we tend to do it in name only. We take individuals and we take their time and focus and break it into small pieces and distribute it across multiple projects. This denies the individual the ability to actually affiliate with any individual team. We leave the individual contributor as an individual rather than a member of a team.

Timeboxing has an antidote for this, but before we get to that let’s take a look at some of Peter Drucker’s theories about teams. Drucker says there are only three kinds of teams. There is the baseball team, the tennis doubles team, and the soccer team.

The baseball team is the way we traditionally form teams in product development. You take an individual with a particular skill, fit that person into a position needed in a particular project, and you give that person a series of rules. Their behaviors are then based on reactions to stimuli based upon those rules. If you lose a person on a team like this you replace them like a cog in a machine; with another individual that has a similar skill set and also understands the rules of behavior. This sort of team is absolutely inappropriate for product development. It works very well in manufacturing, but is wrong for product development.

The other two types of teams are deployed in the timeboxing system and are appropriate for product development. Timeboxing system is lead by two leaders. One is responsible for the priority of the work being done. The second individual is responsible for making sure the work actually flows. These two individuals have each other’s back. If one for any reason can’t fulfill their responsibilities, for instance if they’re going to visit a customer, the other person rushes in a takes their palace. Not dissimilar to what a tennis doubles partner would do.

The real important team in a time box system is the execution team — the development team. The individuals work as a unit. They move through the work together like a soccer team moving down the field. In our observation, as we’ve put together development teams together in timeboxing, we’ve seen a collaboration starting almost immediately. One of the behaviors in the time box system is dialogue. This dialoguing leads to a shared understanding of the work and a shared vision of how it’s going to be executed. You gain the benefit of mutual mentoring inside of timeboxing where the knowledge of any individual is shared with the team and people inherently learn from each other.

Finally, as we said, there’s a correlation between team behaviors and quality. Not only is the inherent value there, but the commitment to quality actually rises in a team as they move through the time box system. Teams in timeboxing are true teams and gain all of the benefits of team behavior. Benefits that we tend to throw away through our use of nominal teams most frequently used in product development.

That’s one benefit of the timeboxing system. In the next post we’re going to talk about another benefit, which is the benefit that comes from the natural work and process limitations imposed by the time box so that the work being executed and the capacity of the team to execute the work are perfectly matched.

Follow Bill at http://www.twitter.com/systhinking

Lately we’ve been talking about the problem of engineering efficiency and the amplification of that problem through overburden; work coming into the engineering group without increasing capacity. To get engineering efficiency we think there are seven things that are necessary:

Understanding what work is active in your organization
Understanding what work is waiting to become active (backlog)
The ability to reprioritize work on a regular basis
The ability to estimate the effort required for any project

Those are the four ideas that most organizations are familiar with. There are three more that are tied to the time box concept.

A standard for capacity utilization
How much engineering efficiency and time do you hope to get out of each engineer in creating value for customers on a regular basis?
Right-sized Communications
How do your engineers communicate with each other. How is communication for forward looking work managed? And how is progress communicated from the technical side to the business side. Ideally this is done using visual communication. In he Time Box concept this is done easily at the end of each cadence period.
Operating your team as a team
We tend to operate our engineers as individual contributors and simply call them teammates. But, when we take their capacity and distribute it across multiple projects we really disenabling their affiliation with a team and operating with team behavior.

This problem, the problem of teams and breaking engineers into tiny chunks, will be covered in other posts. But for now we’d like you to understand that the concept of time boxing can be a huge driver in the increasing of your engineering efficiency.

Follow Bill at http://www.twitter.com/systhinking

Today I want to talk about one of the key lean concepts, the concept of cadence. We’ve been talking about engineering efficiency and we’ve talked about getting projects off to a clean start. Today I want to talk about keeping projects moving forward and keeping a high level of engineering efficiency within projects. To do this let me talk first to Michael Kennedy’s concept of two value streams within product development. Mike’s thesis says there are two value streams — The knowledge value stream and the product value stream. Many of you will think of these as research and development.
In Mike’s concept all of the knowledge gaps, the things we need to learn to be successful in the projects we’re undertaking are the first things you do. You invest your upfront work to close the knowledge gaps. The second value stream is where you take all of your knowledge and march the development of the project to market. In the way Kennedy lays it out, the backend or value product stream can actually be put on a schedule or clock and run to hit time-to-market. The front end, the knowledge value stream, can’t be put on a schedule. You can’t put learning on a clock. You don’t know when the actual learning that necessary is going to occur.

So, how do you drive work in this upfront learning cycle of product development? The answer is simple. You use a recurring period. Many of you probably have a recurring meeting with your supervisor every week or every couple weeks. That recurring period is to keep things moving forward progressively. The same can be done with the work in engineering. The use of a regularly repeating periodic pattern is Cadence — a key Lean concept.

You can use Cadence in driving learning by putting in place short-term deadlines. This helps keep focus on the learning work that is being undertaken. It gives the people doing the learning or research a chance to demonstrate progress or get feedback. It also gives the supervisor of the researchers a chance to nudge them back on course if they’re moving off course and following a different bend or path that may be cutting into their straight-line path to engineering efficiency.

This concept of Cadence is used in product development in various places in various contexts. It’s used in Japan in what is called “integration Events.” The leader of a project will meet regularly with a team to check their progress and provide instruction for what should be included in the next cadence period. It’s used in software development. It is seen most clearly in the “sprint” of Scrum software development. Recently it’s also been used in hardware development. There is an emerging concept called “Time Boxing” which uses cadence as a way of keeping progress on track. We’ll be speaking more about Time Boxing in this series, but for now, just understand that if you’re interested in increasing your engineering efficiency from the pathetic levels that are standard in the US now to something that resembles a cost effective use of those resources — Time Boxing is really something that is worth investigating.

Follow Bill at http://www.twitter.com/systhinking

We’ve been talking about some of the issues with Product Development. Today I’m going to talk about a problem present at the start of projects. There is consistently a lack of clarity in the goals or requirements coming into engineering. Software development has made significant progress in managing this problem, but in hardware engineering it persists.

Clarity of goals is important. Clarity is one of the hallmarks of an achievement culture. If you’re trying to achieve something in a project the more clear things are at the beginning the faster you can make progress and the better you can make headway towards the accomplishment you’re trying to achieve.

We used to hear about engineering “throwing things over the wall” to manufacturing. There is a similar problem at the beginning of a project where work is thrown over the wall into engineering without any kind of clear objective or explanation of what is trying to be accomplished. In our consulting experience we’ve run into companies where individuals have spent the beginning of a project just trying to understand what is being asked of them and what a project is all about. Once they’ve figured it out they still need to gather whatever supplies or materials they need to start making progress towards the goals of the requested work. Both of those steps are absolute efficiency killers. If you’re familiar with the efficiency statistics in engineering, then you know that the amount of time engineers typically spend engineering and creating value for customers is pathetically low in US industry.

Software rather than hardware has made significant progress in improving efficiency. They have done two things to increase the efficiency of their resources: implemented the use of use cases (Use Cases explain how somebody is going to use their output product), they also use “stories” in software development techniques such as Scrum. In the case of stories, someone making a request of software engineering will make a request and the request will have three specific parts. The request will say 1) who it came from (name and role of the person making the request) 2) what is being requested (generally the statement of “what” is very simple) and 3) what is the benefit that will be recognized by the organization (the benefit statement of executing the work)

When something like a Scrum “story” is generated, it doesn’t go directly to an engineer’s desk to be executed. There is another step that is fundamental to the role of managers. This step ensures engineering efficiency is optimized and removes anything other than the executable work from the engineers. This is the role of filtering the requests. Filtering requests can take various forms and is done by managers. It is in place to make sure that when that work arrives on the desk of an engineer, the goal of the work is absolutely crystal clear. This is the primary lever of change that will enable significant increases in software and hardware engineering efficiency at American organizations.

Follow Bill at http://www.twitter.com/systhinking