Write. Teach. Do. Three essential steps to being recognized as an expert.

There are two fundamental pillars to being an expert. The first, obviously, is being an expert. In other words, performing the hard work of learning and practicing to gain expertise in your chosen profession. The second, and which is the topic of this post, is your reputation as an expert. Anyone can claim to be knowledgeable about a subject or profession. The question is how do you separate the posers from the real experts? The answer is through evidence: specifically, building a body of evidence that demonstrates expertise in your profession. So let’s start with:

Writing
A time honored tradition for demonstrating expertise is to write about it. Pick a subject related to your profession and write a paper about it. This not only demonstrates mastery, but doing the research needed to write intelligently about a subject will enhance your knowledge and make you even more of an expert. However, in order to build the body of evidence needed to enhance your reputation, you need to have your writing published. And, fortunately, the Internet has provided a very easy way to do that: a blog.

People write blogs for many different reasons. But the main purpose of a professional blog is to provide a centralized means of publishing evidence of your expertise. Whenever you publish research on your blog, it documents your expertise. If you do this routinely once or twice a week, you will soon create a substantial body of knowledge and evidence. You will also create a body of research for your own use; I often find myself referring back to blog posts I have written to refamiliarize myself with topics I have written about and for inspiration on future topics. You will undoubtedly do the same. Which leads into the next step:

Teaching
Few things demonstrate mastery and expertise than teaching others. When you become a teacher, you are the de facto expert in the room. Not only that, but doing the research needed to prepare for a lecture will enhance your knowledge. But how do you leverage this as documentation of your expertise? By publishing presentations and webinars to your blog.

Did you get up in front of a room of people and give some training? Most likely you developed a presentation as a part of it. Add some notes to your presentation and post it on your blog. Don’t have access to a group of trainees? No problem. Develop a webinar and present it online. Does it matter if only a couple of people log in when you present it? No! What matters is that you can record the webinar and post it to your blog. Whether someone attends the webinar live or views it later is irrelevant. What is important is documenting your ability to relay your expertise in a teachable manner, and to further enhance the body of knowledge you build on your blog. This also leads to the third step:

Doing
Writing and teaching are important steps for building expertise, but you also demonstrate mastery by doing. Did you write about some new technique related to your profession? Go out and practice it! And then document what you learned through practice and post it to your blog as evidence. Did you go out on a job and do something different? How did that work out? Write about it and add it to your body of knowledge.

Another aspect of doing is documenting your experience. You can create a resume page on your blog and add to it whenever you do something relevant. You can also create a page on a professional networking site, like Linked In, and link that page to your blog and vice versa. This will help to drive traffic from one to the other and help to get the word out.

You will also need to get out and network. Are there local events related to your profession? Go to them and put a face behind your blog. Are there professional blogs and online groups you can become a member of? Join them and constructively comment on others’ posts. Have a professional business card ready at all times to hand out, and make sure you have the url to your blog on your business card. After all, what better way to impress a potential contact than to have him or her log onto your blog and experience that amazing body of knowledge and mastery you have created as evidence of your expertise?

Finally, you need to loop everything back into your writing and teaching. All three steps—writing, teaching, and doing—are mutually reinforcing. By documenting this mastery on your blog, you will create a unique and personalized body of knowledge that will allow you to stand out as an expert in your profession, and provide a resource to help you advance to the next level in your career.

With Lean, the team is everything

There is no “I” in Lean. No matter where it is implemented, no matter the domain, or industry, or location, the single most transferrable part of Lean is the formation and support of highly motivated and focused teams. Period.

True, there are many features of the Toyota Production System that are applicable to other industries, such as quicker response to business demands, more flexibility, improved quality, better communication across the organization, the ability to accomplish more with less, and so on. But if you are considering moving your company to Lean, then you need to understand that these highly desirable features exist to either directly support communication within and between teams, or they exist because these teams have discovered that these are what work best for Toyota in its role as a global producer of cars.

This concept is so important that it bears repeating:

1. The features of the Toyota Production System are there because
2. they either directly support communication within and between teams or
3. because these teams have discovered that these features are what work best
4. for Toyota in its role as a global producer of cars.

In other words, the features that make Lean desirable were conceptualized by the teams of workers who were (and are) challenged daily with the questions of how best to improve quality, decrease switching times of production lines, improve communication, and all the other things important to Toyota.

Does this mean that Lean is applicable only to Toyota, or global car manufacturers? Of course not! Lean has deservedly earned its reputation for vastly improving operations in many different industries. It truly is a better way of doing things. But the takeaway here is that without motivated teams, any attempt to transform an organization to Lean is either doomed to failure outright, or doomed to suffer through the nightmare of trying to graft a system meant for something else onto its own. The best way to implement Lean is to establish the teams first, and then task them with doing what Toyota’s teams have done: figure out the best way to improve the characteristics that are most important for your organization.

Now that we understand that, then implementing Lean should be simple, right? Just put some motivated teams together and you’re good to go. Wrong! Anyone who has attempted a major change initiative will tell you that engaging people to change organizational culture is the most difficult part of creating enduring change. And Lean suffers more than most because most of the obvious things that make Lean so sexy pertain to the business, not to the people.

These are the things that businesses care about: productivity, profit, market share, and growth.

These are the things that people care about: career paths, salary growth and benefits, job stability, and feeling engaged.

When people hear management touting initiatives like improving efficiency and eliminating waste, often what they hear are layoffs and having to do more with less. Nobody wants to willingly support that. So how do you align the message with something your people will willingly support? The short answer with Lean is that you can’t. Unless you can match increased productivity with growth, then some people are going to lose their jobs. That’s just the nature of the beast with transforming to Lean. Toyota may be the world’s largest and most efficient car manufacturer, but it does it with half the people of GM.

So, how do you motivate your people to transform to Lean? A good place to start is with IT. IT departments are notoriously overworked and understaffed, so this is a place where growth can overcome the efficiencies gained by Lean and showcase how people’s working lives are, indeed, much more engaged and empowered during and after the transformation. Form a couple of self-organizing teams and task them with the second most important feature of Lean: process improvement. With Taiichi Ohno of Toyota, that started with the creation of stamping machines in which the dies could be swapped out and calibrated in a matter of minutes instead of hours, thus allowing production lines to be swapped very rapidly. Are there similar transformations in efficiency that can be made in your IT department? Turn your teams loose and find out.

If you don’t have an IT department, then look for another department that is similarly overworked. You have one, because all organizations are bottlenecked somewhere. Locate the bottleneck and start the transformation there. Once that transformation is underway, then move onto the next bottlenecked department, and so on, following the bottlenecks until the organization is transformed. And don’t stop there, because the third most important feature of Lean is that this process never stops.

It is not easy to transform to Lean, and the predominant reason is a failure to understand the importance of highly focused and motivated teams in the process, because the root essence of Lean is highly focused and motivated teams. By conducting the transformation in such a way as to allow growth to overcome fears of job loss and impact on employment, then the teams will be more receptive to the many ways in which Lean can benefit them. All of the other business friendly aspects of Lean flow from that.

An Agile Primer: A Tale of Three Manufacturing Processes

Imagine, if you will, an industry where every product is unique. When a client wants something built, he or she first contacts representatives of the industry, who then work with them to capture requirements and design the solution. The work is then passed off to highly trained specialists who make each piece of the solution. Some work directly for the hired company, but much of the work is also outsourced to independent contractors who follow their own standards. When the various pieces of the solution are brought together, highly trained specialists then fit them together by customizing each piece to fit with each other, resulting in no two solutions being exactly alike, even if produced according to the same plans. Because all solutions are fundamentally unique, each requires extensive acceptance testing prior to receipt, and issues generally require expensive fixes by more highly trained specialists. No solution is ever produced entirely error free. Post-delivery, each solution requires expensive, highly trained specialists to troubleshoot, fix, and maintain. And so on.

An Agile Primer: The Lean Principles

As a concept, Lean means many things to many people. In very general terms, however, Lean is the practice of focusing on that which creates value while eliminating that which creates waste. Within the domain of manufacturing, a general definition of Lean is perhaps the customer-focused restructuring of the continuous flow assembly-line processes pioneered by Henry Ford to allow the rapid set up and production of a wide variety of product offerings on the same line, but with the same continuity of overall flow achieved by mono-selection mass production. Within the domain of software development, a general definition of Lean is probably close to that of Lean manufacturing: the customer-focused ability to rapidly produce a wide variety of novel software solutions to novel business problems, under conditions of high uncertainty and quickly changing business environments that render Traditional staged planning and development ineffective. Whatever the domain, though, Lean is invariably grounded in the basic definition: focus on the value and eliminate the waste.

An Agile Primer: The Agile Development Domain

As Mary and Tom Poppendieck point out in Lean Software Development: An Agile Toolkit, principles are the guiding ideas and knowledge of a domain, while practices are the implementation of those principles for a specific application. For example, a venerable supply-chain principle is that stored material helps to smooth out production by eliminating the wait for it when needed, while use-cases, requirements analysis, and other knowledge documenting activities are practices utilized to implement this “stored material” principle within the application of software development. However, the translation is problematic because supply-chain management as practiced in the 1950’s and 1960’s (which is when the practices of Traditional project management were originally derived) was based on increasing the production efficiency of mass-produced products, and is not readily transferrable to an application which is closer to new product development than to the repetitive production of thousands of identical widgets.

Manufacturing, as a domain, has also moved on since the practices of Traditional project management were established, as has the management of manufacturing projects. Indeed, the Toyota Production System and the just-in-time supply management principles developed by Dell are more in line with new product development than mass production. Thus, the manufacturing principles upon which Traditional software development is based no longer even broadly apply to manufacturing. In other words, if one were to attempt a reverse translation of Traditional software development principles and practices, the result would very likely no longer match the needs of modern manufacturing. Therefore, by extension, software development techniques derived from Traditional project management suffer greatly because they rely on a translation of manufacturing principles of questionable applicability that no longer even broadly apply to modern manufacturing. This is a very important concept, because it is foundational to the argument for incurring the substantial cost, effort, and risk of migrating from Traditional to Agile Development: If one assumes that the validity of Traditional software development is due to its strong link to the large scale, monolithic manufacturing principles of its day, then Agile Development should be no less equally valid due to its strong link to the modern Lean manufacturing principles of today.

Thus, if we view Agile Development through that lens, then what it represents is not just some counter-cultural method of managing software development projects, but a necessary realignment of software development practices with modern manufacturing principles. This realignment is in response to four important needs of modern software development, discussed below.

First, a fundamental constraint on any project is the need for the development team, executive suite, stakeholders, business owners, domain experts, and end users to converge on a solution that meets the needs of all of the above. Traditional software development attempts to achieve this convergence through a lengthy, up-front requirements gathering process that is designed to capture the needs of the various stakeholders and translate them to the development team in such a way that a solution can be defined and agreed upon prior to development. However, this is predicated on a number of assumptions: (1) that stakeholders know with certainty what they want at the beginning of a project, (2) that these needs can be captured and translated in such a way that developers can understand them well enough up front to define and produce an acceptable solution, (3) that the business environment will not change significantly between the time the requirements were gathered and the time the solution is deployed, and (4) that significant events will not occur during the course of the project that will substantially alter the first three assumptions. Software development very rarely meets all of these assumptions, therefore there is a need for practices optimized for helping the development team and stakeholders gain and maintain convergence on solutions in an atmosphere of high uncertainty and rapid change.

Second, a highly important need for software development is the need for rapid development and deployment to market. Since a requirement for Traditional, predictive software development is a frequently lengthy and resource intensive up-front planning process, this often precludes a rapid start to development. Given the quickly changing business environment of many software development projects, this delay in producing a useful deliverable increases the risk that the target market may have moved on since the time the project was initially conceived, hence reducing the applicability of the resulting solution. Therefore, there is a need for development practices optimized for rapidly identifying and producing deliverables that can be quickly deployed and consumed by the target audience.

Third, software development (and projects in general) benefits when high value features can be developed and deployed early, as this speeds up the rate at which the return on investment (ROI) can be realized. Since Traditional projects are usually structured to deploy the completed product all at once, the order of development is customarily optimized for the most efficient development timeline, regardless of the level of desirability of the individual components. Thus, the priority of development is often based on the optimization of the development process, and not the priority of the stakeholders. However, in keeping with the need for rapid development and deployment, it is important that the development process prioritize business need over efficiency of development; hence the need for software development practices optimized for identifying and sequencing high-value deliverables for deployment early in the development process. This gets the higher valued, higher ROI features in the hands of stakeholders
sooner for immediate capitalization and feedback into subsequent development, maintaining convergence and keeping outputs more closely aligned with a changing business environment.

Finally, because projects continuously vie for finite resources, it may be advantageous to be able to easily end a project early once the higher-priority features have been delivered so that resources can be redirected to another project. Since Traditional software development is usually predicated and optimized for the delivery of all identified features and functions, regardless of business value, this makes it difficult to evaluate and stop Traditional software development before all outputs have been developed and deployed. Hence, the need for software development practices optimized for allowing the early closure of a project once the high-priority deliverables have been deployed. Thus, to summarize, modern software development practices need to be optimized for the following:

• Conditions where early convergence on a complete solution may be difficult to achieve due to a high degree of uncertainty and the potential for a high degree of change during the course of a project.
• Conditions where there is a need for rapid development and deployment of high value, high ROI deliverables to take advantage of early capitalization and feedback.
• Conditions where it is important to prioritize (and reprioritize) business need over development efficiency in order to speed delivery of some, but not all, outputs of a project in response to rapidly changing business requirements/environments.
• Conditions where changing priorities make it beneficial to have the ability to easily and successfully end a project early to shift resources to higher priority projects.

This is not to say that Traditional software development cannot be configured to meet the needs identified above. Indeed, many of the tools associated with Agile Development can be incorporated into Traditional projects to make them more adaptive to uncertain and changing needs, requirements, and target markets in such a way as to prioritize development and make them easier to end early, such as is the case with Lean manufacturing. However, in order to incorporate these tools, it is beneficial to understand the types of uncertainties and associated project types, and the sensitivity of these project types to uncertainty and change, further elaborated in the subsequent posts of this primer.

An Agile Primer: Why Agile Development

Because Traditional project management has a long history in the engineering and manufacturing fields, its processes and procedures have evolved primarily for the purposes of optimization and coordination. Since process optimization is associated with efficiency, it is particularly well suited to projects in which the ultimate goal is the improvement of repetitive and/or assembly line processes in order to minimize waste and increase both productivity and predictability. It also follows that projects that require a high level of coordinated activity between teams and processes benefit from the ability to optimize the predictability of outputs, since it is obviously difficult for a team to predict its resource needs and outputs if it is dependent on another team for which the outputs are unpredictable.

The fundamental issue with using Traditional project management techniques to manage software development projects, however, stems from two problems. The first is related to the fact that software development has much more in common with new product development than standardized manufacturing. The second is that, by nature, the change and uncertainty associated with new product development defy optimization and render many of the optimization-based tools utilized by Traditional project management ineffective and, in many cases, self-defeating.

Much like new product development, the output of a software development project is almost always a first time endeavor. Although the processes utilized to develop software can be somewhat standardized, the end result of the project is invariably a solution to some unique problem. Therefore, software development is much closer to the development of the first of something than optimizing the production run of something already defined. For example, consider the development of a brand new type of minivan as opposed to the optimization of production after it has been developed. It should be obvious that the challenges and toolset related to the former should be substantially different than the challenges and toolset related to the latter. What Agile Development does, therefore, is create a toolset more closely aligned with the challenges related to the successful development of new and unique solutions.

An Agile Primer: Measuring, Monitoring, and Reporting

Projects accumulate metrics for three fundamental reasons: to monitor the performance of a project against an agreed-upon baseline, to provide standardized measurements to predict performance on similar projects, and to predict the future performance of the project in relation to the definition of success.  As with many things, though, the definition of success means different things to different people. Also, when translating principles across domains into practices, it is important to understand the reason for the underlying principle as it applies to the target domain. Thus, when it comes to translating Lean Manufacturing principles into Agile Development practices, the definition of success is important, since this is ultimately what a project will be measured against, whether it meets the cost and time constraints or not.

Nearly all manufacturing processes are designed to optimize two things: efficiency and customer satisfaction. When it comes to mass production, this is usually defined as conformance to a specification of the ideal widget being produced, within acceptable tolerances. Bolts of a certain size will all be the same size, televisions of a certain model will look and perform exactly the same, and so on. This is because, for these items, the specific design requirements to meet end user desires have already been worked out, and the measure of success is how efficiently they can be produced so as to minimize cost.

Conversely, almost all software development projects represent some level of variability from the norm, including establishing what “the norm” is if the project is to develop something for the first time—which is usually the case. Thus, the measure of success for new development projects is not conformance to some idealized specification, but the degree to which the resulting solution meets the desired purpose. Even well-defined rewrites are subject to this measure, since the assumption is that the requirements have been designed with the intent of meeting the current needs of the end users, and not efficiency of development. Obviously, this has a fundamental effect on the metrics that are used to measure and report the status of an Agile Development project

As stated previously in the section on self-organizing teams, team members on Traditional projects are usually assigned to specific roles as resources to be utilized as needed, using standardized estimates for planning purposes, with the assumption that the activities that comprise a software development project can be generalized and measured in a way similar to mass production on an assembly line. While this is generally sufficient for high-level estimating, the reality is that although roles can be quantified on a project in theory, the performance of real people in these roles varies widely, both from person to person, and from project to project for the same person, because every project is different. To overcome this, Agile Development favors measuring aggregate team performance and user satisfaction instead of individual performance against a standardized norm. This facilitates collaboration and teamwork by focusing the entire team on producing outputs that meet the needs of the end users, and allows the self-organizing nature of Agile Development teams to collectively manage individual performance issues. While this is an appropriate measure for Agile Development, it becomes problematic when measuring the aggregate performance of a portfolio made up of both Traditional and Agile Development projects. One strategy for accomplishing this Earned Value Management (EVM).

Traditional Earned Value Management (EVM) is a robust project management technique for measuring the performance of a project against cost and schedule baselines by quantifying chunks of work in terms of cost (dollars) and time (hours). As a team “consumes” these chunks of work, it establishes a performance metric which can be used to predict future performance. A variation of this for Agile Development, called Agile EVM, utilizes the same calculations as Traditional EVM by substituting story points for hours. This provides project managers with a seemingly uniform measurement of project health that can be presented to portfolio managers and project steering committees that are used to seeing EVM metrics for Traditional projects, with the following important caveat.

All projects are measured in terms of three metrics, often called the triple constraint or Iron Triangle: outputs, cost, and time. With Traditional projects, the outputs are considered inviolate, and variability in a project is absorbed as a function of time and cost. In other words, if all promised items must be produced, then differences between the projected baseline and reality must be reflected in adjusted costs and/or development time. Thus, Traditional EVM is a measurement of the team’s cost and production efficiency measured against an inviolate development schedule, and a healthy project is one that is performing at or below cost and at or ahead of schedule.

With Agile Development projects, however, it is cost and time that are considered inviolate, and differences between the projected baseline and reality are reflected in an adjusted development schedule. In other words, Agile projects run for a fixed time period and cost, and the amount of output produced is what is variable—what is commonly called “flipping the triangle.” The problem with this, of course, is that EVM assumes a fixed scope of development (relayed as cost) and production rate (defined by the work schedule) as the baselines against which performance is measured. Since a fundamental part of the Agile Development process involves continuously refactoring the development baseline as the team narrows in on the needs of end users, this brings into question what information it is, exactly, that the EVM metric on an Agile Development project is relaying, as refactoring the baseline alters the EVM calculation, making comparison with previous values difficult or meaningless. It is quite possible to make an Agile Development project always appear on schedule, after all, simply by refactoring the schedule! Therefore, EVM should be used with caution on Agile Development projects, and primarily ones where the backlog, user requirements, and look-ahead plan are relatively stable, and there is a desire to remain so. Indeed, since EVM is merely a measure of performance against a baseline, the utility of using it needs to be weighed against its propensity for focusing development on achieving conformance to the performance baseline instead of achieving the ultimate measure of success, which is end user satisfaction.

A more relevant performance metric for Agile Development projects is the rate at which the development team can produce outputs that satisfy the needs of the end users, in relation to the size of the backlog of user stories, and within the allotted time and resources allocated to the project. This is called the burn-down baseline for the project, and the metric against which the actual burn-down rate is measured. Thus, for example, if the MoSCoW process for a project produced a backlog estimate of 120 story points, and an iteration period of 1 month was selected for an estimated duration of six-months, then the team would have to develop stories at a rate of 120/6, or 20 points/iteration that are accepted by the user to complete the project as initially defined. A project team that is developing user accepted output at a rate that meets or exceeds 20 points/iteration can be said to be a healthy project. Projects for which the team cannot meet this rate of user acceptance need to be quickly reevaluated.

Note that the burn-down metric is based solely on story points and not the actual stories themselves, allowing the team to readjust the development schedule as conditions change on the ground, and to swap in new stories if needed as they are discovered during development, without affecting the burn-down rate. Changes in the number of total story points on the backlog would alter the burn-down baseline and, when compared to the actual burn-down rate, may trigger discussion as to whether additional people need to be added to the project, or the size of the backlog reduced. This provides a consistent measure for determining the health of a project that is disconnected from the actual development schedule.

From a portfolio management perspective, however, the burn-down metric may be problematic due to the fact that a similar measurement does not generally exist for Traditional projects, since end user satisfaction is not measured until the very end of the project, when gap analysis and closure are performed. However, it is possible to plan Traditional projects in stages (aka, Iterative Waterfall), such that end user satisfaction can be periodically measured at the end of each stage for comparison purposes.

An Agile Primer: Operations and the “Backlog Lifecycle”

In the simplest sense, the product backlog for an Agile Development project may be described as a prioritized list of user stories representing the desired features and functions for a product. As a tool for estimating, controlling, and baselining product development, the backlog has a beginning, a middle, and an end. This can be defined as the “backlog lifecycle,” shown in the figure below:
The backlog lifecycle consists of six basic steps: (1) backlog seeding, (2) backlog grooming, (3) story development, (4) story closure, (5) story grooming, and (6) story approval. It begins with the seeding of the backlog with stories derived during the initial (MoSCoW) planning for the project, and each loop around the lifecycle represents the period between backlog grooming sessions and/or a development period/iteration for the project. These loops continue until the end of the project, or the backlog has been reduced to the point that another project takes priority, with various on-ramps and off-ramps for stories during the course of the project. When a project is closed and placed into maintenance mode, the backlog may continue to be “seeded” with stories until such a time as a new development period for the project begins, at which point the backlog lifecycle recommences. This is a profoundly important Agile concept in relation to strategic planning and portfolio management: a product backlog does not necessarily close at the end of a project. It may merely cycle back and forth between periods of activity and inactivity based on the state of the backlog and its aggregate priority in relation to all of the other projects in an organization’s portfolio. The six steps of the backlog lifecycle are elaborated below.

An Agile Primer: Agile Estimating and the “MoSCoW Process”

One common criticism of Agile Development methodologies by those used to more predictive methods is that Agile Development does not guarantee that all listed features will be completed by the end of a project. However, this is by design. What Agile Development does promise to do is to focus development on the features most relevant to the end users first, while providing the option to add more if time permits. This is an important distinction.

An Agile Primer: Goal Decomposition and “Iteration 0”

All projects, Agile or otherwise, start off with a pre-planning process, even quick-start projects. The difference is in the level of planning involved. As described above with respect to the Schedule Stack, Agile projects start off with the construction of an overall project plan, including the charter, business case, project management plan, cost and duration estimates, and other traditional project management artifacts. For lack of a better term, this initial planning process can be termed “Release 0,” with one of the outputs being the high level, overall schedule for the project, shaped into 3-6 month releases (or phases/stages), with applicable release goals identified for each release. For large projects, this is often referred to as the product or multi-year plan.