The Role of the Process Owner

Learn more about transforming people, process and culture with the Real Agility Program

The following is an edited version of a post to the Scrum Development Yahoo! group made by Dave Barrett (CSM) (used by permission):

The ScrumMaster (Process Owner) role itself doesn’t automatically imply any degree of authority, although at times it does help when you need a little clout to clear some impediments or to negotiate with other departments. More than that, the ScrumMaster role does carry a responsibility to provide some leadership to the team. Even a self-organizing team needs leadership!

So I would say that it helps if the ScrumMaster has a little bit of
seniority over the rest of the team, it also helps if the ScrumMaster
approaches the role as a coach and leader, rather than as a supervisor.

On paper it looks like the ScrumMaster only has a few tasks:

1. Chair the Scrums, and make sure they happen each day. (The self-organizing team’s regular status meetings.)
2. Chair the Sprint (Iteration) Review and Planning meetings.
3. Produce the burndown chart. (An information radiator used to indicate the amount of work left in the product work item list and in the iteration work item list.)
4. Do the team’s “paperwork” – publish the Sprint Backlog (product work item list) once it has been set and so on.
5. Clear impediments brought up during the Scrums.

In reality, the ScumMaster needs to do a lot of other things. There’s all of the leadership stuff, keep the team happy, productive and motivated. There’s the political aspect, keeping other groups and
departments happy and out of the team’s hair. As the in-house “expert” on Scrum, you need to referee on points of procedure and theory. Often you need to champion Scrum within the organization.

Really, I don’t see a huge difference between the roles of Project Manager and Scrum Master. Semantics mostly. Project Manager almost seems to imply a “command and control” approach, Scrum thrives best
without that. I wouldn’t make a junior programmer a project manager, nor would I make him a Scrum Master.

Please share!

Agile Offshoring References

Learn more about transforming people, process and culture with the Real Agility Program

Many people are trying out Agile Work in software development. The current industry climate is one that has focused business stakeholders’ attentions on re-examining their core priorities. Where Agile optimizes on “Time to market”, the offshoring “over-the-wall” approach to software development seeks to optimize on raw dollar cost.

What do you do if your organization is attempting both? There are some good resources on-line about this already, however I have yet to see good case-studies with published figures. Also, much of what’s out there comes in the form of mini-articles that are no more than promotional ads for X proprietary “agile-offshore” solution. Regardless, some of the following may help avoid the worst problems of integrating two quite different approaches.

Please share!

Harvard Business Review Article

Learn more about transforming people, process and culture with the Real Agility Program

I highly recommend this article on Collaboration Rules. Great stuff in there about developing teams, developing organizations and how important communication and trust are to doing so. The article draws examples from and compares the open-source development and maintenance of the Linux kernal and the operation of the Toyota Production System.

Please share!

Using Agile Work Practices to Develop a Seminar

Learn more about transforming people, process and culture with the Real Agility Program

I’ve been working on developing a Agile Work Seminar to introduce teams to agile work. I’m using some Agile Work practices to develop it.

Iterative Delivery and Adaptive Planning

The seminar is going through drafts. Each draft will actually be delivered to a team. The first time through all the material was done at a small software consulting company five days ago. As a result of feedback from the people who participated, a revision will be made to the seminar… and then it will be delivered again (probably the next time will be in early September). This process allows me to refine the contents and presentation of the material.

Over time, I will be able to use Adaptive Planning to modify the contents and qualities of the seminar as circumstances change.

Test-Driven Work

I have set up criteria for the presentation in the form of an outline and learning objectives. The outline describes the major topics that must be directly covered such as the Agile Axioms or Corporate Culture. I have also set up “soft goals” such as that the seminar must include theory, history, practice and criticism of Agile Work. My first iteration met the outline tests, but did not meet the soft tests explicitly. The next version will.

Appropriate Metrics

This is an easy one: the success of this project will be its acceptance in the marketplace by having teams willing to pay the price for this seminar and then recommending it to others.

The Other Practices

Because this is essentially a one-man job, the other practices such as Self-Organizing Team and Maximize Communication are not as applicable.

Please share!

The Viable Systems Model

Learn more about transforming people, process and culture with the Real Agility Program

Agile Work is a system that can be created inside many types of organizations and work environments. I recently came across an interesting article about the viability of systems. The article describes an interesting recursive breakdown of systems into sub-systems of specific types. Over the course of the next few weeks, I will use this model to try to analyze Agile Work to see if it is viable.

Please share!

Trust and Small Groups

Learn more about transforming people, process and culture with the Real Agility Program

A while ago I posted the story of a student film project using agile practices to create a documentary. One interesting observation made by the instructor is that trust among the group developed in an interesting fashion.

At first, the group self-organized by try to work in groups of three. However, when plans were made to get together (for example to film an interview), often, one of the three people would cancel. Probably, that person considered two people to be enough to do the work.

After noticing this pattern, the group decided to perform work in pairs. This made the commitment to working much stronger and eventually led to a more trusting work relationship.

I have also observed this pattern in other situations. Pair programming, pair writing, pair designing, pair problem-solving… all of these behaviors seem to arise naturally in a self-organizing team.

Please share!

Just-In-Time Value Delivery and Waste Elimination

Learn more about transforming people, process and culture with the Real Agility Program

Lean Manufacturing

If I am manufacturing computers, and I receive a large batch of CPU’s… say… Intel Pentium IIIs, I put them in inventory. There is a recurring montetary cost associated with keeping this inventory. There is, however, also a hidden cost. If I use up half my inventory to build computers, and then I inventory those computers, and I ship half of those computers, I now have 3/4 of my initial chips waiting around, earning me no money at all.

Then, Intel ships the new Pentium 4. What happens now? Well, I basically have to throw out my Pentium 3 stock (either by making low-cost, reduced-margin computers just to get rid of them, or by trying to sell the chips wholesale at cut rates). I also have to either slash prices on my remaining stock of computers, or re-fit them with the new processors. All of this is very expensive, and may eliminate most or all of the profits I was expecting to make on the original purchase. It is a scenario that is rife with waste.

Most manufacturing industry players have figured this out, and moved to a Just-In-Time model of production. Toyota pioneered much of this in the 1970s, and now inventory is seen as a liability, rather than an asset. This waste-free approach is a centrepiece of the Lean manufacturing revolution

Waste and Inventory in Software Development

Unfortunately, there is a parallel in computer software creation that has been rather poorly understood by businesses that need custom software development. Waste can be considered as anything that is unfinished, and/or unused. In software development terms, this can be applied to documents that will never be read or that might be unnecessary, and other such things. It is also true of unfinished software.

Traditional Software Development Example

Let us suppose that we ask someone to develop a piece of software with thirty features. Let us further suppose that this software will take about twelve months to produce. Let’s further suppose that ten of these are business-critical features, and that all of the features’ definitions are highly market-driven.

So a traditional software project starts to develop them. First there is a requirements analysis phase, then a design phase. Throughout there are lots of approval stages, sign-offs, etc. Then some team codes up the software starting somewhere around month five. Coding proceeds for about three months, after which the software goes through a testing process in month nine. In theory, at the end of this testing process (month twelve), we are supposed to receive the software for use, and we should be able to receive the value it was supposed to offer. However, defects are found in testing, requiring some re-work. The software is delayed by a further three months, and we finally receive it. By the time we receive it, our competetors have defined new features, and we have to submit new feature requests, whose results will not be seen for several months.

So for the entire development process, we received no business value, and continued to pay. Fifteen months from first investment until we started to achieve results that could mean revenue from the system. At this point, the software is partially obsolete. This is quite similar to the manufacturing scenario above.

Lean and Agile Software Development

Agile and Lean software development practices change this process by delivering business value a little-bit at a time. In an Agile software project, the business specifies what the most important features are (in our case the ten business-critical ones). The team then begins working in small time-boxes – say, two to four weeks. In each time-box, the team works on a small but well-defined list of features taken from the top of the prioritized feature list that we specified. At the end of the time-box, those features that were worked on are delivered to a degree of quality that each of the delivered features would be suitable for use by the customer. The whole might not be ready, but any features worked-on would be complete and production-ready.

If the team can average about three features per month (about what they pulled off in the above example), then by month four, the team could deliver a piece of software that has all ten business-critical features ready for use. The whole might not be ready, but the customers could determine whether those ten were worth taking the software in its current state, and packaging it up and deploying it. Quite simply, the software may not be “done”, but it’s “done enough”. Then the team can continue to roll-out less valueable features from the prioritized list.

Market and customer needs volatility

This becomes even more important when we consider the competition’s changes. In the traditional example above, after fifteen months, additional features were required. These may have been discovered in month six. Traditionally, these could only be considered in month sixteen. In Agile and Lean software development, however, work on these changes could be started in month seven or sooner. So the business received value early, or “just-in-time”, and they could get high-value changes “just-in-time”.


Because testing is built-in to the process, the customer is able to validate the product at the end of every time-box, so there are no large batches of re-work. The only time large batches of rework are necessary are when large changes to the basic requirements are requested. And then, Agile does not resist the customer’s desire to change, but recognizes it as an essential part of software delivery, and adapts to the changing consditions. As a result, the Agile and Lean methods are optimized to produce quality product in small increments, so quality doesn’t suffer from customers or markets changing their minds.


Agile and Lean principles are very powerful, and allow for business value to be delivered sooner to end-customers. This allows for better quality and risk management. It also allows strategic and tactical decision-making by executives to be undertaken when such decisions are most needed – not six months too late.

Firms that embrace Lean and Agile development principles are beginning to see the competetive differentiation that Toyota saw vis-a-vis the rest of the automotive industry throughout the 70’s and 80’s. It is only in the last two decades that, after adopting Lean practices, Toyota’s competitors have begun to close the gap. Agile software shops are beginning to achieve these same competetive gains. Those who don’t adapt to just-in-time value delivery – who don’t eliminate waste in their processes – will feel the results as their competitors take products and services to market far faster, and with more responsiveness to their customers.

“If you’re not on the steam-roller, you’re part of the asphalt.” – Lighthouse Design, circa 1996.

Please share!

Optimizing a Team Room

Learn more about transforming people, process and culture with the Real Agility Program

Some less-obvious hints for creating a team room that promotes collaboration and effective communication.

– don’t underestimate the importance of plants and natural light for overall morale and health
– encourage the team both individually and as a group to personalize the team space: kid’s art, photos, trinkets, food, special chairs/ergonomic stuff
– encouraging a playful atmosphere if your group is quiet and shy is easier in a bullpen and this in turn leads to better morale
– encourage the team to notice traffic patterns (both physical and communication) and optimize the space to account for these patterns
– play games in the team room during lunch breaks or after-hours and have the results of the games as part of the visual environment

Please share!

The Transparent Society

Learn more about transforming people, process and culture with the Real Agility Program

The Transparent Society, an essay by David Brin is an excellent statement about the possibilities and challenges that technology presents to us as a society. What is interesting about this paper is that it presents a possible society that is very similar to some of the goals in establishing an agile environment: open communication, accountability, free access to information and status, and close collaboration.

Please share!

Value redux (more on business value added)

Learn more about transforming people, process and culture with the Real Agility Program

In a previous article, Mishkin portrayed three kinds of added value that can be considered when analyzing a value stream: Customer Value Added (CVA), Business Value Added (BVA), and Non-Value Added(NVA). I recommend peeking at this article before reading this one.

The second flavour mentioned is Business Value Added. This is, to quote the above, “activity that is required to operate the business but the customer is unwilling to pay for.” I wanted to look at this a bit closer.

Why would we separate this kind of value? On one hand, if the customer wouldn’t pay for it, is it really value? Management and executive would say, “Yes”, since it amounts to operational infrastructure or overhead necessary to the business. By this view, without certain “horizontal” functions, the entire enterprise to which the lean analysis is being applied would not be possible – therefore it’s of immense value to the customer, however indirect. On the other hand, if it isn’t of value to the customer – ie. the customer cannot see the value, then why is it there at all? This is a tough question.

A fanatical Lean interpretation would be to say that this kind of value doesn’t exist. Either a reasonable customer would be willing to pay for it, explicitly, if indirectly, or it simply is not value added. In essence, business value added can be seen as something of an allowance – a departure from the sharp scalpel of lean value-stream analysis. Its purpose is to provide to those who do these “BVA” functions some explicit value, since these are often those whom lean analysts must convince of the accuracy of their analyses. By this interpretation, BVA is strictly a cop-out. It doesn’t provide value to the product/service produced, and is therefore a target for waste elimination.

There are very good reasons to look at BVA from either side. The discipline of waste elimination on one hand, and validating necessary if unprofitable work on the other. As in most things, a balanced view is wisest here, and perhaps BVA is merely a short-hand for such a view. BVA, like NVA is waste. However, there are some necessary and unavoidable wastes.

Traffic lights are on all night, even when cars aren’t available, because no one has figured out an efficient way of turning them off until cars appear. It’s necessary infrastructure. But it is waste. It’s power being consumed without result.

A full highway is a jammed highway. Having about 15-20% capacity under-used actually tends to optimize the on-ramp-to-off-ramp cycle time. Here is unused roadway, where clearly one could fit on more cars. Yet, according to queueing theory, this localized “waste” is necessary in that it optimizes the whole system. Such system-supporting overhead is counterintuitive, but bears itself out in many natural systems.

The process of tracking project progress does not improve the final product, but it aids in the organization of the corporation/entity that is providing the initial funding, and satisfies necessary requirements that are not direct from the customer. It may result in better resource allocation, for example. The daily meeting is time not spent on the product, but those 5-15 minutes can unjam horrible project roadblocks. Eliminating this “NVA” or “BVA” step would be catastrophic for the whole system.

Because BVA, like NVA, is waste, it should always be examined for reduction and elimination. Unlike other NVA, however, I would argue that BVA is that minimum NVA activity that cannot be trimmed, without unduely sacrificing the effort as a whole. By calling it NVA we keep it in perspective. Perhaps it might be better called “unavoidable non-value added” (UNVA) activity. It’s value is not direct, and it is effort and resources taken away from the customer. Where possible, it should be eliminated as NVA. However, those who perform these functions can rest assured that, once the process is leaned-out, what they are doing is unavoidable and necessary work.

BVA (UNVA) can be a very useful tool for clarifying process, so long as the analyst doesn’t get sloppy about treating it as waste.

Please share!

Generalizing Specialists

Learn more about transforming people, process and culture with the Real Agility Program

The term “generalizing specialists” has come to mean an individual who has a particular area of deep expertise but also has experience in a large number of other areas that may not be directly related to their core area. This type of person typically has strong talent in their specialty but also has a generally strong talent for learning new skills and ideas quickly. The origin of the term seems to be in the software industry referring to programmers who can do other software-development related tasks.

In self-organizing teams, a generalizing specialist is a more valuable team member than a pure specialist. The pure specialist often has an attitude that they should not need to do work outside their specialty. This can be destructive to the team’s morale. On the other hand, the generalizing specialist is willing and able to learn new skills – to stretch as the needs of the team change. And since change is natural, this is an essential attitude for team members.

However, we are usually trained, and strongly encouraged to have a deep specialty. This approach to education and training is a natural consequence to the typical organizational model for work and society. Therefore, if a team is converting to agile work methods, people need to be coached to stretch themselves and learn new things. For some people, particularly those who already have multiple hobbies outside work, this is an easy transition to make. For others, it is a very difficult transition. In some extreme cases, this may call for the removal of someone from the team. (Note: I have never seen this myself and I only mention it with great reservation. I strongly feel that only those who could be called “ill” will be so incapable of changing their way of working. For other recalcitrants, it is usually a matter of motivation.)

Other terms that are similar to “generalizing specialist” include “craftsperson”, “renaissance man”, and “polymath“.

Please share!

Just In Case You Haven’t Seen It Yet

Learn more about transforming people, process and culture with the Real Agility Program

There is a fantastic article about software productivity: I love Joel’s writing style, and this article in particular has important lessons for us all, regardless of our profession: find what you can be the best at, and do that. Interestingly enough this is part of the message of the book Good to Great but applied to a whole corporation. It also applies in the context of self-organizing teams: each individual should be able to find/learn in what way they can best contribute and do that more than they do other stuff.

Please share!

Agile for IT Infrastructure Upgrades

Learn more about transforming people, process and culture with the Real Agility Program

I recently had the pleasure of coaching a team through the use of agile methods to run an IT infrastructure upgrade project. As a coach, I was there to observe and guide, to inspect and adapt. The goal of the project was to upgrade a critical piece of software that was at the end of its support life, and at the same time upgrade another piece of software to a more recent minor version. As well, new hardware would be used to run the updated software. All of this is in the context of a mission-critical system used by a major US financial services corporation. Let’s call this project the “System Renewal” project or SR.

Prior to deciding to use agile methods, the SR project was defined using two non-agile requirements documents which listed in detail what the results of the project shall and shall-not be. One was the “business” requirements and one was the “system” requirements. For example:

SR-BR 0030
Description: The SR upgrade shall maintain the same or better level of performance.
Requirement Priority: Essential
Source/References: Joe Somebody
Comments: The SR version x.01 shall be upgraded to the x.02 as a part of this project.

I worked with some key people to review the project requirements before beginning. We decided that we would hold a workshop with the team to accomplish three things: introduce the team to agile methods, provide some initial team-building opportunities, and to introduce and launch the project with the team. The team decided to use two week iterations and to shoot for a single release after four iterations. Since this was much faster than the time estimated using the old waterfall methodology, there was a large margin of safety in case a second release was necessary.

During this workshop, the team re-organized the requirements into larger “user stories” and smaller tasks. This process of re-organization allowed the team members to collaborate and to get to know the nature of the project in more depth. There was a challenge here: the work to be done had nothing to do with end users. The team along with some guidance from myself and some other coaches, decided that the “user stories” would be very similar to the top level of a traditional work breakdown structure (WBS) and the tasks would be the second level. As much as possible, dependencies among the user stories were avoided so that they could be re-organized from iteration to iteration as circumstances required.

Once the project launch workshop was complete, the team immediately moved into the first iteration planning meeting. In this meeting, the team estimated the size of the tasks and selected the user stories to be completed in the first iteration. The basic idea was to accomplish one main goal: to upgrade the software on a small number of systems (the total number of systems to be upgraded was about 15). A secondary goal was to make some progress on automating a set of system tests to include in a regression suite. Prior to this project, all the tests were done manually. No new tests would be created as the functionality of the system would not be changed.

The first iteration went fairly well: from our burndown, it appeared that not much was accomplished in the first six or seven days of the ten day iteration. The last few days were extremely productive and the main goal of the iteration was accomplished. Some progress was made on automating tests, but that was not actually finished so manual tests were used to confirm the operation of the upgraded systems. During this first iteration I acted as the team’s coach by facilitating the daily status meetings, maintaining the burndown charts, and trying to resolve impediments to the team’s progress. At this point, impediments were mostly related to the physical and techinical environment: lack of phones, whiteboards, system access, etc.

The team had a half-day iteration reflection meeting that focused on questions about estimation and tracking of task status. The customer representative accepted the work that had been completed although an actual demonstration was not performed.

The second iteration was planned as the first. A few days in, the second challenge was encountered: the existing manual testing revealed that the new version of the software had modified some interfaces with other systems. As a result, the software did not work. The team temporarily halted its work in order to examine the problem and try to determine a solution. The team quickly got in touch with the vendor of the software and a simple fix was planned that would be deployed near the end of the second iteration. Some re-organization of the iteration’s user stories and tasks was done in order to accomodate this problem. This was done in collaboration with the customer representative.

At this point it should be noted that this was a first for the organization: testing early revealed a problem that normally would be discovered right at the very end of the project rather than right at the beginning. This allowed the team to re-organize their work to remain productive and so there was no change to the schedule. This is one of the main benefits of the combination of iterative delivery and test-driven work: the early discovery of problems and the ability to work around them without substantial schedule or scope impact.

The second iteration concluded successfully. The third and fourth iterations were relatively uneventful. And the team deployed the upgraded systems more than two months early. No new software was created. The key practices used either fully or partially included: self-steering team, iterative delivery, adaptive planning, test-driven work, and maximize communication (use of both co-located team and information radiators). The question of appropriate metrics did not come up except insofar as the team was substantially exempted from the corporate procedural compliance measurements, and was operating in an environment where time-to-market was considered the most important factor.

Please share!