Category: management

Posted on

Launch of Geri’s Latest Book

Did you get your free Bonus Materials for my new book “Why Agile is Failing at Large Companies (and what you can do so it won’t fail at yours)”?

Visit the book website at http://agileisfailing.com and click the BONUS Materials link on the upper right of the page.

You can also add your email to my notification list. You will get notices when I post new bonus material, hold webinars, speak in public, or publish another book.

Thanks to everyone who is supporting the launch of my book. I am most grateful.

Posted on

Scrum Roles – One Liners

Scrum Master – enable the scrum team to work as efficiently and effectively as possible

Product Owner – ensure there is a steady stream of well-defined valuable work available for the scrum team to work on

Team Member – work together to deliver high-quality production ready results at a steady, sustainable pace

Posted on

How Your Waterfall Project Can Be More Agile

5 Practices to Make Any Project More Agile

A core foundational concept in Agile is to get feedback from real users early enough to be able to address any issues that arise.  In traditional Waterfall, we assume we can do enough work up front that there will be no issues at the end, but reality shows that this almost never happens. Instead, at the very end of the project, we do User Acceptance Testing and discover issues that we either rush to patch or we plan a follow up project to address them.

Even if your project cannot adopt an Agile methodology, there is a better way to do Waterfall that still lets you take advantage of all the experience you have doing Waterfall projects and requires very little change within your organization.

There are 5 practices we strongly recommend because they can be done by any project following any kind of methodology. We have in practice with real projects seen them dramatically improve the results of Waterfall projects, and in fact have found historical evidence that some of these practices were recommended in the past for Waterfall efforts. These 5 practices are:

  • Divide the work into increments
  • Plan, estimate, and prioritize each increment
  • Synchronize work including vendors
  • Demo each increment
  • Retrospective each increment

This is what as known as Incremental Waterfall with the addition of the Agile practices of work synchronization, demonstrations of progress, and multiple retrospectives. For Waterfall projects, these practices should not require much change to current processes. Some of the phase gates may need to be passed each increment, such as detailed requirements or design each increment, so some additional time should be allowed for in the schedule. The time is made up later when better quality leads to shorter test cycles and involvement of users means much less (if any) late rework. Big picture work such as overall planning, high level requirements, architecture, and solution selection can be done at the beginning because they are common across all increments and typically do not change much throughout the project lifetime.

In general the approach for a Waterfall project will be a relatively short up front planning, requirements, and architecture phase followed by a set of increments for implementation. Each increment will include the work of detailed planning, requirements, design, implementation, and testing. The complete release process may take place at each increment if desired, or may be delayed until the end of the project.

Each practice is described in more detail below.

Divide the work into increments

An increment is a working subset of the overall solution. This practice would mean examining a project to determine the best way to divide it into 2 or more incremental deliveries of working solution. Note that these deliveries do not have to be general availability, but rather could be collected in a holding area until the whole solution is complete. But each increment will go through a full test cycle including especially user acceptance testing.

The criteria for determining what goes into each increment should include business value (the most valuable work should be done earliest), risk (we should use feedback from real users to drive out risk as early as possible), and the ability to deliver a working subset of the overall solution (minimum viable product). This practice by itself has dramatically improved traditional Waterfall projects by providing feedback well before the end of the project.

In fact, this practice was proposed for Waterfall projects in 1970 by Dr. Winston W. Royce based on his previous long time experience with large Waterfall projects (Managing the Development of Large Software Systems, Proceedings IEEE Wescon August 1970, pages 1-9). His experience and research showed that there would almost always need to be at least a second increment of a Waterfall project to refine the solution based on lessons learned, and so teams should just plan for it. We see the same realization at most of our large customers, where large Waterfall projects have typically been followed by another improvement or fix-it project. We are suggesting to formalize this practice with multiple planned increments of any software project.

Plan, estimate, and prioritize each increment

No matter the length of the increment, the detailed work planning, refining of estimates, and prioritizing of work should happen not long before the start of the increment, instead of doing all of it up front for the whole project. This allows the flexibility to take advantage of lessons learned in one increment to apply to the planning for subsequent increments. It is also a good time to review project metrics to verify the work is going according to plan, and allows a planned time to make adjustments as needed rather than waiting for the end of the project to discover there are issues.

We expect high level planning at the start of the project for all except the most innovative and fast-changing work (which by nature cannot be planned much in advance). This practice is to wait to do detailed planning until just before you need it so that the plans are the most accurate based on the information you have to date. This practice avoids spending time doing detailed work that is likely to be changed later in the project. The less well-understood the work is, the more important this practice becomes.

Synchronize work including vendors

Everyone involved with the project should regularly synchronize their work, including a representative from each vendor. This synchronization can take the form of a daily standup. In some cases, that may be more frequent than needed, but this synchronization should take place at least weekly. Synchronization should be often enough to remove the risk of unnecessary delays due to unknown work blockages.

Note that this is not meant to be a long status meeting, but is rather a 15 minute or less structured ceremony where each person just states what he or she has recently completed, what work he or she is working on now, and anything preventing (blocking) the person from completing his or her work. The most important information to come from this meeting is typically the blockages. The work blockages can be addressed after the synchronization meeting.

It is very important that the vendor representatives be included. A big problem when working with vendors is lack of visibility into what they are working on. Communication can be difficult already when working with another company, so anything we can do to promote regular, meaningful communication will improve (sometimes greatly) the work we do with vendors. Our customers who have worked this way with vendor representatives report a uniformly better experience than just handing work “over the wall” and expecting everything to be fine.

Demo each increment

At least once per increment, the working solution is demonstrated to at least the project sponsor and stakeholders. By far the better choice is to have real end users also attend the demonstration. This demonstration has two purposes: it provides a real deadline when work has to be finished so that it can be demonstrated, and it provides an early opportunity for users to provide feedback on whether or not the solution meets their needs.

Note that this does not replace formal user acceptance testing, but rather is a demonstration of progress and an opportunity for feedback well before the end of a project. Instead of providing status through reports showing perhaps 85% of requirements are completed (for example), we demonstrate working solutions as a measure of progress. If the solution is not complete enough to be demonstrated, we count it as zero percent complete.

We treat solutions as zero complete or 100% percent complete and do not try to determine an increment in between. This is because with any kind of knowledge work, it is not actually possible to truly determine how much is left to do. We can only know how much has been done. We all know of cases where the solution was 90% complete but that last 10% took 90% of the resources. We prevent that in this practice by only counting a 100% solution as complete and anything else as zero.

The demonstration provides a good opportunity to review the progress of the project to get an idea of whether it is on schedule, ahead, or behind. The outcome of the demonstration is that either the work to date is acceptable as is, or defects or change requests are created to fix problems that are detected at the demonstration. The work to fix the defects or change requests can be planned into subsequent increments of the project so that these problems do not exist in the released version of the product.

Retrospective each increment

Most companies have some kind of retrospective or lessons learned at the end of a project. Unfortunately, that is too late to do any kind of good for that team. Instead, at the end of each increment, the team will review the past increment, and in a non-judgmental way discuss what went really well, what did not go so well, and what they will do in the next increment to improve as a team.

We suggest the team start the retrospective by reciting a statement such as “We acknowledge that everyone has done the best job they were able to do in the circumstances that existed during this increment” and suggest the team end the retrospective with expressions of gratitude and thanks to other members of the team or even people outside the team who helped in some special way (it is nice to let those people know in person that they did a great job if they do not happen to be at the retrospective). This helps set a non-judgmental tone to the ceremony. The most important thing is to avoid blaming and finger pointing, to make the ceremony constructive.

The outcome of the retrospective is a small set of specific action items the team will take to improve the coming increment. We recommend starting with just 1 or 2 action items so as to not overwhelm the team with improvement work while they are focused on delivering a product. Often the outcome of the retrospective are suggestions that become habits over time, as the team incorporates better and more efficient ways of working together.

Posted on

Setting up Your Programs for Success

With all the conversations about SAFe, you would think programs were a new idea. Actually, they have been used for many decades to manage very large efforts. This article discusses lessons learned from the past about how to set up a program at the beginning so it will run more smoothly throughout.

A program is one kind of construct to organize and coordinate the work of a large number of people on the same deliverable. Other constructs include value streams, products, product families/lines, and the open source model (community ownership of software with rules and governance). I have heard of programs as small as 40 people contained within one company and I have been personally involved with programs involving hundreds of people, sometimes across several companies or countries. Programs are used to manage big efforts.

Programs were developed in the defense industry to manage efforts such as putting a man on the moon, creating a new submarine, or creating an overall battlefield management system. Programs were adopted in commercial enterprises to manage efforts such as SAP implementations or creating a new tractor. Creating a mobile app does not require a program.

Programs are used to manage large complex efforts. A key technique to managing complexity is to structure the work in such a way as to get rid of as much complexity as possible. Simplify as much as possible, then manage the rest.

When planning your program, assign work to individual teams in such a way as to reduce or remove dependencies between teams. Each team should work as independently as possible. There should be little or no dependencies based on time, code, functionality or any other factor.

You can achieve this independence by assigning complete independent work packages (for example use case, user story, subsystem, component, or task) to each team. If the work packages are truly independent, you should not have very many cases where multiple teams need to work in the same code base, nor should you care much about what order the work is completed.

Any points where the teams need to cooperate should be well defined using tools such as contracts, interfaces, services, or API’s. Test harnesses and stubs can be effectively used to keep the work of the various teams as independent as possible, allowing each team to test their own code even if code they need to use from another team does not yet exist.

Teams should NOT be set up around the SDLC, i.e. a requirements team, design team, coding team, and testing team. This creates unnecessary dependencies between teams such as the coding team is waiting on designs, the testing team is waiting for code, etc. Each team should be responsible for the complete life-cycle for the work package they are assigned.

You do have to plan coordination points for releases. Teams cannot work on whatever they please. Each team has to make a commitment to deliver certain functionality at a certain time with specified quality. This is a commitment to their co-workers on the other teams. There may be other work a team does as well, but there has to be a minimum set of code they complete by a specific scheduled date in order for everything to fit together. You have to carefully manage the teams so they deliver what they promised the other teams at the time they promised to deliver it. If you do a good job defining the integration points between teams and managing their work to complete on time, then integration of the work of the various teams should be fairly straight forward.

There has to be a program level management team whose job it is to create the appropriate work packages, set up the release schedule, assign the work to the teams, define the minimum each team is required to deliver to make the release, coordinate the work of the teams, remove obstacles between teams, and be the final arbiter in situations of disagreement. People managing the program may include architects (software, system, network, data, UI, business) as well as those in more traditional management roles. You may need people at the program level to create (or help create) code that coordinates the work between teams such as test harnesses, stubs, interfaces, services, or API’s.

While you can do a whole program with one release at the end, this is very high risk. Programs tend to be lengthy and much can change from beginning to end. It is much better to plan a series of releases with time scheduled to make any needed adjustments due to change or lessons learned.

In a well structured program, you do not have to care about how each team does their work. As long as the team delivers according to their contract, it does not matter if they are onshore, offshore, or vendor, or whether they use an Agile or Waterfall type of SDLC.

Finally, the key to a well-run program is monitoring the teams and their progress with appropriate metrics, regular meetings with a representative from each team to coordinate efforts, management by walking around when you can, and quick resolution of problems when they arise.

Posted on

Lean Startup Ideas for Mitigating Business Risk

All businesses exist to deliver the right product or service to market, at the right time, for the right cost. All business risk fundamentally puts one of these items in jeopardy, and so our fundamental business risks are:

  1. Failure to deliver the right product or service

  2. Failure to deliver the product or service at the right time

  3. Failure to deliver the product or service for the right return on investment (ROI)

  4. For companies in regulated industries we also have failure to comply with all laws and regulations

These risks are fundamental to business, and do not change based on the processes or procedures used to create or deliver the products or services. All risks we identify that are specific to processes or procedures must address one of these fundamental business risks.

For example, business continuity procedures help some companies, such as those that deliver SaaS or hot line support, ensure that they deliver the product or service at the right time. In this case, business continuity procedures are extremely important for staying in business because delivering the service at the right time means the service is available all the time.

In addition, we should consider the cost of controlling that risk versus the effect it has on the business risk. Controls that have a small impact on the fundamental business risks should either not be used or should be very inexpensive to implement.

As one example, many companies say they have a risk of project failure, which they define as going over schedule, over budget, or both. I have worked for a number of companies who delivered every project on time and on budget, and their products failed on some or all of the fundamental business risks. I have worked for a number of other companies who did not always deliver their projects on time or budget, but did in fact deliver the right product to market at the right time for a very nice return on investment. In these cases I observed, the risk of project failure did not have a strong correlation to a fundamental business risk. Controlling for project risk only weakly controlled for business risk.

What that tells me is instead of assuming that the project lifecycle is the problem, we should do a root cause analysis to determine the actual problem. Maybe we are running projects poorly. Or maybe we are failing in marketing and sales. We should find the real problem and invest in controls that have a strong correlation with product success.

What is a control? By definition a control is a process that reduces risk. Typically a control is a mitigation strategy that is formalized. Documents are not controls. Documents are also not evidence that a process was followed. We all know of delivery teams who did not follow a specified process but created the document that “proved” they did at the end of the project. I have seen many documents that were supposed to prove that a process was followed, that were merely copies from another effort. Many times, the project name was not changed throughout the document, nor the dates when the work was supposed to have been done.

A control is a process. Therefore, if you want to audit for the control, you have to audit the process. Most of the time, that will mean observing the process as it is being done. If all the auditors do is look for a document that says the process was done, then you have incurred cost with zero benefit. If your company is typical, your people never have enough time to do everything, so they will cut processes that are only audited by document and do the fastest job possible to produce the required documents. Since the process is most likely not being done, either the process is not necessary to control for risk or you have been lucky.

Given all that, what are associated risks and mitigations for the fundamental business risks? Below are some examples of possible risks and mitigations for the fundamental business risks listed above. The mitigations are heavily influenced by Agile and Lean Startup thinking, so may or may not be appropriate for your business.

Business risk: Failure to deliver the right product or service

Associated Risk Mitigation
Your market is not well-defined Leadership in the company should go through an exercise of defining the market for each product and service. They might be the same, they might be different. It is not good enough to say “Our market is men.” Or “Our market is middle-aged people.” It is almost certainly true that those markets are too big. Get specific.
You do not understand your market Company leadership should ideally be from your target market or have a close relationship with your target market. You can also use focus groups, advisory boards, and other techniques to get a better understanding, but there is no substitute for personal knowledge.
The product or service is poorly defined This is common early in product development, but must be mitigated before the product or service goes to market. The best mitigation is to do a little, test it with users, based on feedback do a little more, test again, and continue this until you have a viable product. Whatever prototyping you do, find the least expensive, fastest way to do it.
The users do not want the product or service The best mitigation is to get real users involved in developing the product or service. Not just one group of users (you end up developing something just for them), but bring in many different groups of users over time who represent the breadth of your market.

Business risk: Failure to deliver the product or service at the right time

Associated Risk Mitigation
You deliver too early Find real users who are connectors and recommenders. Get them involved in the development process. Encourage them to help prepare the market for the coming product.
You deliver too late Identify a minimum viable product. Develop that first, and keep it always ready to go. You can release that at any time if you have to quickly go to market and follow up with additional features later.
You deliver too often Solicit feedback from real users all the time – forums, blogs, Facebook page, etc. They will tell you if they are getting overwhelmed. When possible, track the use of the different product features. If you are delivering new features and no one is using them, you are probably delivering too often.
You deliver too infrequently The same as delivering too late, always have something new ready to go. Solicit feedback from real users all the time. They will tell you if they are tired of waiting for new features.

Business risk: Failure to deliver the product or service for the right return on investment (ROI)

Associated Risk Mitigation
The size of your market is smaller than you thought Discover if there is a broader market who can also make use of your product or service. Cut back on your product plans to match the size of your market.
Your market is not finding out about your product or does not see the value in it Assuming you have identified the right market and product, then along with traditional marketing, find connectors and recommenders, get them involved in developing your product, encourage them to recommend your product to others. Also, look for related products where you can piggyback your marketing efforts. Joint marketing with another company could be quite effective.
The cost of development was too high when compared to sales or other benefit received (low ROI) Identify the root cause. Were you overly ambitious compared to market demand? Then you need to cut back on your development efforts. Was the development process inefficient (heavy process, too many people, too many metrics, too many meetings, not enough experience in the development team)? Bring in someone to help improve your process. Was the failure in the sales team – not enough sales to recover the cost of development? Maybe you need more experienced sales people, or they need better training on the product and benefits, or they need coaching on sales techniques.

Business risk: Failure to comply with all laws and regulations

Associated Risk Mitigation
Discovery of non-compliance and the consequences of it (product removed from market, product reworked, fines, prosecution, restitution) Educate your workforce on the laws and regulations. Review product and service offerings with lawyers, regulators, and other experts as appropriate. Keep records of all recommendations by lawyers, regulators, and experts. Be aware when there are changes and have your product and service offerings reviewed for compliance with new laws and regulations. Be sure all product and service offerings are updated within the time frame allowed.

I hope this article has you thinking more about how to control for risk. Doing the same thing “everyone else” is doing may not be the right thing for your company. Go back to the fundamental risks and discover the best way for your company to reduce them.

Posted on

Six Sigma versus Business Analysis

Six Sigma Business Analysis
Purpose Remove defects created by a process Discover user needs and align with business objectives
Approach Remove variations in the process Feedback from users
Main Skill Set Statistics Analysis
Objections Forget to ask should we even do this, or is there a different, better approach. Most people are really bad at statistics. Removing all variation inhibits innovation and growth. Too often just an order taker or list maker. Analysis is not a common skill.
Posted on

The Myth of 100% Utilization

I have gone into many a company whose managers brag to me about their 100% utilization of their people. They have all the techniques down pat and know just how to do it. I see opportunity. If they are willing to listen, I can improve their productivity 20-50% by not trying to get 100% utilization.

 

First, some terms need to be defined. Availability is the amount of time someone is available to do the job you hired them for. If they are a programmer, they are programming. If they are tech support, they are working with customers. If they are a tech writer, they are writing. Utilization is the amount of the available time that the person is actually doing the work. Many companies count utilization as the percent of hours a person bills to a project. That is merely how someone charges their time, not a measure of what they were doing in that time. To improve utilization, you have to improve both availability and utilization.

 

To know the actual time someone is working at their job requires observation. Many of these studies have been done for knowledge workers of all kinds, where the researcher follows someone around all day, tracking the time they spend on everything they do. They do this for maybe hundreds of people (multiple researchers of course) over an extended time. Companies pay for this research because they are looking for inefficiencies in their processes. Fortunately a lot of this research is published and the results are very consistent. This means you can use averages instead of paying for the research at your company.

 

The highest availability anyone has measured was 80%. Your most productive people are available at best 80% of the time to do their jobs. This is actually a good thing! They are not doing nothing in the other 20% of their time. The other time is spent on things such as company town halls, training, meetings with their boss, meetings with their team, and so on. When you think of all the things that pull people away from their work, 20% is a quite reasonable number for those kinds of activities. You want to allow your people time for career development.

 

You think that the contractors you hire must be at 100% availability. Of course they are 100% available for the hours they bill you. If they are billing you at 40 hours a week, they are almost certainly putting in about another 10 hours a week on their own time (or their staffing company’s time) for these other activities.

 

If you really had 100% availability, you would have unhappy, burned out employees who quickly leave for better opportunities.

 

So far, we know we cannot have 100% utilization of people’s time because they need about 20% of their time for activities other than the actual job you hired them to do (programming, writing, tech support, etc.). But what about 100% utilization of the 80%? We can use all our management tricks to get that number; we do it all the time!

 

Maybe.

 

Let’s consider all the things that prevent people from working 100% of their available time. Start with task switching. If you assign people to two or more projects at a time, you are losing on average 10% of their time every time they switch between projects due to having to switch their brains from one project to the other. Averaged out, this amounts to about 20% loss of productivity for each project you add (because people don’t usually just switch once between projects). This number is extremely well established based on about 90 years of research. It is real, it is going on, whether you want to admit it or not.

 

The first step then is to focus your people on one project.

 

But you say you have specialists and they don’t have that much work to do on one project. Then cross train them. The specialist model has been well studied and shown over and over to be inefficient. It looks appealing on paper, but actual measurement in real life shows that specialists lose most of their time to task switching. You are not getting much actual work out of your specialists anyway, so leave them in one place and teach them new skills.

 

The second step is help your people gain additional skills so there is more work that they can do.

 

A final common cause of lack of utilization is the huge number of interruptions due to telephone, e-mail, instant messaging, texting, and so on. For best utilization, you want to focus your people’s time on one project and you want to focus their attention. Get rid of the sources of interruption for some number of hours every day and add practices that help them focus on their work. Since you only have 80% availability, make that 80% as interrupt free as possible. For 6 hours a day, no phone, email, texting, or IM. Seat the whole team together so they do not need to use phone, email, texting, or IM to communicate with each other. Have them work in pairs to stay focused on the job.

 

The final step is to put people who work together in one place, remove interruptions for 6 hours a day (phone, text, email, IM), and have them work in pairs as much as possible.

 

There are companies who have taken these steps and watched their productivity soar. Companies who deliver products to market at 1/10th the cost of their competitors. Maybe you don’t get that much lift, but what is the value to you of a modest 10% gain? What if it was 20%? Is that worth changing they way you staff your projects?

Posted on

Different Ways of Managing Work

Managing Work

Inside your company, many different kinds of work are being done. Rather than examining the work and then deciding how to structure it, most companies take a one size fits all approach. Many companies have decided that everything has to be run as a project, so they hire a lot of PMPs and set up systems to track the progress of a project. Other companies see success using Scrum in software development so they decide that everything has to be run using Scrum teams, and they hire a lot of Scrum Masters, and usually still try to account for the work as projects (though more enlightened companies fund Scrum Teams instead). Other companies fund product teams and all work is accounted to the product.

The fact is that all of these approaches work (as do many others). Where we make a mistake is treating all work the same way. The reason it is a mistake is that when we organize work in a manner not appropriate to the work itself we introduce unnecessary overhead and cost. You can keep doing everything as a project or everything as Scrum, just know that the work of your company is more expensive than it needs to be.

A Fluid company will look for the best way to do work based on the type of the work itself. In this post, I will examine three primary ways of managing work and discuss the kind of work that fits each management technique. These three ways of managing work are: project, product, and workstream.

Projects

Many companies structure all their work in the form of projects. What they do not realize is that for most companies, about 10-25% of the work of the company fits a project framework. For everything else, the project framework introduces a lot of unnecessary overhead.

First, what is a project? A project has a beginning, middle, and end. A project is completed and there is no work left over. A project is formed to achieve a specific goal or end state. A project has a schedule and budget. The schedule and budget of a project are measured throughout to show the progress of the project. Companies using an Agile methodology for software development (such as Scrum) add a regular measurement of the progress of the actual product being developed to the project metrics.

To run work as a project, you have to define the goal or purpose of the project, estimate the total cost, assign people to work on it, get everyone up to speed (project kickoff), estimate the tasks to be done to achieve the goal, run the project measuring schedule and budget throughout, and finally deliver the results of the work and close down the project.

Work that is “one and done” fits the project model very well. Things such as buying and installing third party software, upgrading all the workstations in the company to the newest version, converting a 40 year old system to new technology, and building a new company cafeteria are all examples of things that fit a project model.

Work that is repetitive and demand driven, or planned and ongoing, does not fit a project model very well. This is for two reasons. First, each repetition of the work requires defining, estimating, setting up and tearing down the project. That is a lot of overhead over time. Second, by dividing the work up into projects, you lose the long term vision of the work and almost always this results in suboptimal short term decisions leading to long term inefficiencies and cost.

Things that are repetitive and demand driven include customer support, setting up a work area for a new employee, releasing a product, or emergency response. These things should have standardized procedures and be managed as workstreams.

Things that are planned and ongoing include adding features or fixing non-critical bugs in an existing product, initiating a new product that you expect to have a lifetime longer than a few months, creating and regularly delivering training, doing competitor research, and any ongoing work that is not demand driven in nature. This kind of work should be organized around products or systems

Products and Systems

Products and systems are things that your company is responsible for maintaining over some lifetime. Systems are inside your company and generally exist to support the work of the employees. Products are things that you provide (or could provide) to customers, partners, or vendors outside your company. The important thing is not whether something is a product or system, but rather is this something that your company has to maintain over time.

Products and systems can be things such as computer hardware, computer software, business processes, training, and reports for a few examples. While products and systems do have a beginning, middle, and end, the lifetime is generally measured in decades, not months. There are products in the market today whose lifetimes are measured in centuries. When managing products and systems, the important measurement is the lifetime cost of ownership. Projects focus on the short term cost, often leading to decisions that make the product or system more expensive to maintain over time. Products and systems should not be maintained as a series of projects; over time that is far too expensive.

To manage work as a product or system, you form a product or system team. This is a small number of people whose job it is to create, maintain, and manage the product or system over time. This could be as small as 2 people (never one – you do not want to depend on one single person knowing the product or system), or for large products being actively maintained you may have 20 or 30 people on the team (or more). The product or system team is responsible for the long term vision of the product or system, the architecture or design of the product or system, the development of the product or system, the maintenance of the product or system, and the release plan for the product or system. The cost of the work is in the size of the team; team members are paid full time to work on the product or system team.

Work comes in continuously in the form of defect reports and feature requests from users, product managers, and company goals and directives. This work is organized into releases by the product or system team. The releases may be monthly or quarterly, or the team may decide on continuous releases, as we see with many mobile apps. The release schedule will be driven by market demand and the ability of the users to consume the changes.

The measurement of success is did we deliver the right product at the right time for the right cost. This will be measured every time a release is made and the team sees how the users react to any new features or fixes.

A lot of “run the company” work is associated with a product, but may not fit as part of the product team. If you are an insurance company and have a life insurance product, then creating actuarial tables is part of creating the product and so the actuary is part of the product team. On the other hand, handling claims is not part of creating or maintaining the life insurance product. It could be considered a product (or service) in its own right, and since it is repetitive and demand driven, it is a better fit for a workstream model.

Alternatively, legal work is often directly associated with a product. For some companies in highly regulated industries, a lawyer should be part of the product team, as well as possibly a compliance officer. For small, stable products these people may not be full time on the product team, but are rather a resource to be called upon as needed.

Workstreams

A workstream is a way of structuring work that is repetitive and on demand. The repetitive work should be described by standard processes and procedures. Work comes into a queue which may be “first come first served” or may have some other prioritization scheme applied. Work is managed by tracking the current work in progress to be sure it is not too large. There are typically service level agreements (SLA) which describe how quickly requests are processed.

The processes and procedures themselves are likely maintained by a system team who creates and maintains the processes and procedures, and maintains the software and systems to support those processes and procedures.

The cost is in the number of people staffed to handle the work in the workstream. People work full time handling the work in the workstream. For many people, the continuous pace of work can be very wearying over time, so rotating people between the workstream and the system team may be a way to balance the work across all the people involved.

Success is measured by the quality of the results, by staying under the work in progress limit, and by meeting or bettering the SLA.

The Common Mistake

When considering a company as a whole, structuring the work in different ways makes sense. The common mistake is to categorize all work within a department or division the same way. We see this often in IT where everything is a project. All the systems, metrics, and reporting are designed around projects. And yet, the emergency bug fix team should be a workstream. There should be product teams for each product. And there will be projects as well. But management wants everything reported the same way on one dashboard, and so we are back to everything is a project. (Why projects instead of products? Because PMI and Business Schools train people to manage projects not products, so management picks what they know as the default.)

By forcing everything to be measured the same way and accounted for the same way using the same systems, we are forcing inefficiency and greater cost into our work. These are not small inefficiencies. The unnecessary costs could be as low as 10%, but for most companies, these additional costs may be 30-50% of the IT budget. Just so we can have everything on one dashboard.

Think about it.

Posted on

The Myth of Software Complexity

To claim that software is complex and that therefore we must create large teams to manage that complexity (as SAFe asserts (1)) is missing the point entirely. In this article, I’ll examine the fundamental flaw in that perspective and explain what we really need to do to manage software development in the modern world.

 

Software is complex. I have heard this a lot in my career. It is typically said by either people who do not actually understand software development or by practitioners who want to maintain the mystique of the discipline. Good software engineers know that the best software is a simple as possible.

 

The statement “software is complex” implies that complexity is a fundamental characteristic of software. This is quite obviously not true. If complexity is a fundamental characteristic of software, then we would not have all these clever iPhone apps being developed by individuals, even children, in time frames measured in days. The vast majority of software running things such as your clock, thermostat, and parts of your car is extremely simple. Even the software running robots is relatively simple. The math is complex, the software is not.

 

I’m sure the counter argument is, “OK, all software is not complex. But the software running our businesses and systems, that is complex.” If it is true, then that software is almost certainly unnecessarily complex. Think about most business applications. At its most fundamental, you have a user interface, some business rules, and a database. While the business rules may be complex, the software to implement them should not be. There may be a lot of features, but that does not mean the software behind the features is complex. Many is not the same as complex. Large is not the same as complex.

 

The discipline of software engineering (not coding, engineering) is filled with techniques and practices to remove complexity from software. This is because complexity in software is bad. Complex software is hard to understand, and therefore prone to error, difficult to change, and often full of defects. Good software is as simple as it can be, easy to understand, easy to maintain. Practices such as service oriented architecture, domain specific languages, object oriented design, test first development, refactoring, and minimum viable product all speak to the push away from complexity.

 

As my buddy Kyle points out, you have to ask the right questions. The question is not “How do we manage the development of complex software”, the question is “How do we remove complexity from our software”? Hint: you do not remove complexity by creating teams of 70-100 people running under the structure of a program (2). The Fluid Approach is based on removing complexity in software by using the eXtreme Programming (XP) practices along with good Voice of the User teams made up of Analysts and UI Designers who are skilled at Solution Anthropology.

 

I’m sure someone will bring up this argument “OK, software does not need to be complex, but the process of developing software is complex”. My answer to that is it does not need to be. If your software development process is complex, you have made it unnecessarily so. I have worked for extremely large companies creating big software using a very straight forward, simple development process. You really can create large percentage of the software needed today with teams of no more than 20 people with broad skill sets.

 

If your company has many different programmer roles, tester roles, analyst roles, etc., then you have created an unnecessarily complex process. If you have many layers of people involved in your software projects, then you have made the projects unnecessarily complex. The question is not “How do we manage a complex software development process”, the question is “How do we lean out our software development process”? The Fluid Approach has the answer: cross training, dedication and co-location of the development team with the Voice of the User team, management of the queue, and development of the tribe. These things have been proven to simplify the process of software development.

 

The question is not “How do we manage complexity”?

 

The question is “How do we remove unnecessary complexity”?

 

The Fluid Approach shows you how.

 

(1) “Our modern world runs on software. In order to keep pace, we practitioners must build increasingly complex and sophisticated software systems. Doing so requires larger teams…” http://scaledagileframework.com/ , Why it Matters, accessed 11 May 2014

 

(2) “Trains work best with about 50-100 people dedicated to a primary value stream.” http://scaledagileframework.com/agile-release-train, accessed 11 May 2014.

Posted on

What Metrics Should We Have?

I am sometimes asked “What metrics can we put in place to know that our people are doing a good job?”

They never like my answer. I just want three metrics to start:

1. Are our end users happy?
2. Are our customers (the people paying the bill) happy?
3. Does our team have joy?

They look at me like I am insane.

“That is not nearly enough.” They reply emphatically, “We measure 100s of things. You can’t manage it if your can’t measure it!”

“I agree.” I reply.

“Stop managing and start leading.”