Warning: Table './devblogsdb/cache_page' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_page WHERE cid = 'http://www.softdevblogs.com/?q=aggregator/categories/5' in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc on line 135

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 729

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 730

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 731

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 732
Software Development Blogs: Programming, Software Testing, Agile, Project Management
Skip to content

Software Development Blogs: Programming, Software Testing, Agile Project Management

Methods & Tools

Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!

Process Management
warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/common.inc on line 153.

Agile Coach or Scrum Master

OLYMPUS DIGITAL CAMERAWhat’s the difference between an Agile coach and a scrum master? A quick internet search returns a variety of competing opinions (and a lot of ads for training classes).¬† This is not an arbitrary question – these terms¬†have a great deal of power to set expectations for behavior. While some of the components of the roles are similar, the two roles are different in at least one major way –¬† scope.

Both Agile coaches and scrum masters help teams.  Both roles are tasked with helping Agile teams use Agile values and practices to deliver value to the organization.  Agile coaches and scrum masters use similar techniques to guide, facilitate, and coach teams so that they learn and use Agile techniques, confront delivery problems as they occur, and work together as a well-oiled unit.  If we stopped here the two roles would be the same. However, the scope of the two roles is different.

Agile coaches typically pursue the implementation of an organizational vision of Agile, or are tasked with delivering external knowledge and expertise to a team.  In both cases the coach is external and is not a member any specific project team. In order to effect change from the outside the project, the coach needs a broader exposure to Agile roles than a typical scrum master.  A coach should have played all of roles on an Agile team multiple times. They have the gravitas to influence without direct authority and from outside the team. They interact with a team or teams, and then let the team synthesize and internalize the advice. The Agile coach is typically the voice of Agile at an organizational level.  This generally requires broader exposure and experience with Agile techniques, which is why many organizations use external consultants to play this role. The need for an Agile coach is generally transitory, specifically they are needed when external injections of knowledge or energy is necessary to help ensure the application of Agile continues to evolve.

On the other hand, the scrum master is the team’s tactical coach (scrum defines the team as the scrum master, product owner and the development team). He/she facilitates the team’s use of Agile techniques and helps to protect the team from the outside world. Scrum masters are the voice of the process at the team level.  Scrum masters are a critical member of every Agile team. The team’s need for a scrum master is not transitory because they evolve together as a team.

The role of an Agile coach and that of scrum master have similarities, but also significant differences.


Categories: Process Management

Coach or Manager?

20130520-220059.jpg

Are you a coach or a manager? Most traditional, hierarchical IT organizations use managers to plan, organize and control work. Managers make decisions with greater or lesser collaboration, based on their management style. A coach is a different thing entirely. Coaches exist to assist a team to reach its full potential. In the world of empowered employees and self-managed teams, a coach is an enabler, a guide, and a leader.

A coach enables her team by suggesting areas for self-improvement, ideas for using tools and techniques and facilities improving team. The goal of coaching is to help the team become more effective in delivering value to the organization. The act of coaching requires the ability to interact and facilitate both how individuals and groups work within the team.

When a coach provides guidance, they are using their gravitas to influence the direction of the team. In organizations that rely on control environments, the manager will tell the team the correct direction with the expectation that telling and doing are sequential acts. A coach provides direction and uses her influence to get the team to internalize that direction. The internalized direction may well reflect a synthesis of the team’s knowledge and the coach’s advice.

The ability to enable and guide is a function of being a leader. Kevin Kruse, author of Employee Engagement 2.0, defines leadership as ‚Äúa process of social influence, which maximizes the efforts of others, towards the achievement of a goal.‚ÄĚ The definition does not include the primary tenants of the definition of a manager, control and positional authority, but rather is focused on getting the most from the team through influence.

A coach is a guide and a leader. These attributes are inter-related and self-reinforcing. A coach rarely needs to leverage the techniques of a manager Рplanning, organizing and directing Рrather they rely on influence and team peer-pressure. Are you a manager or a coach? The distinction is stark. Is your role to help the team maximize its value through a process of facilitation? If the answer is yes, then you are a coach.


Categories: Process Management

Software Development Conferences Forecast April 2016

From the Editor of Methods & Tools - Tue, 04/26/2016 - 10:09
Here is a list of software development related conferences and events on Agile project management ( Scrum, Lean, Kanban), software testing and software quality, software architecture, programming (Java, .NET, JavaScript, Ruby, Python, PHP), DevOps and databases (NoSQL, MySQL, etc.) that will take place in the coming weeks and that have media partnerships with the Methods […]

SPaMCAST 391 ‚Äď Mix Tape 2007 ‚Äď 2008, McKnight, Iwanicki, Goldsmith

SPaMCAST Logo

http://www.spamcast.net

Listen Now

Subscribe on iTunes

The first full Software Process and Measurement Cast posted on January 29th, 2007.¬† When the first cast posted we were on an every other week schedule whereas today we post weekly.¬† Over the next few weeks, I will be traveling.¬† The trip is a mixture of vacation and a board meeting but that does not mean you will have to forego your weekly SPaMCAST.¬† In place of our normal format, I will post a mixtape of the answers to the ‚ÄúIf you could change two things‚ÄĚ question I have been asking interviewees for nearly ten years.

SPaMCAST 391 will feature our top downloaded podcasts from the years of 2007 and 2008:

SPaMCAST 2 ‚Äď Will McKnight on Process and Product Quality Assurance

Will used his wishes to talk about the need for an organizational process focus and the guidance to sustain process improvement.

SPaMCAST 4 – Stasia Iwanicki on Six Sigma

Stasia used her first wish to address requirements capture, development, and management.  Her second wish was for better measurement for supporting the software development process.

SPaMCAST 49 ‚Äď Robin Goldsmith on Requirements

Robin used his wishes to discuss the need to capture and validate the real business requirements which lead to better systems.

If you enjoyed the snippets please use the links to listen to the whole interviews.  Next week 2009!


Categories: Process Management

SPaMCAST 391 ‚Äď Mix Tape 2007 ‚Äď 2008, McKnight, Iwanicki, Goldsmith

Software Process and Measurement Cast - Sun, 04/24/2016 - 22:00

The first full Software Process and Measurement Cast posted on January 29th, 2007. When the first cast posted we were on an every other week schedule whereas today we post weekly. Over the next few weeks, I will be traveling. The trip is a mixture of vacation and a board meeting but that does not mean you will have to forego your weekly SPaMCAST. In place of our normal format, I will post a mixtape of the answers to the ‚ÄúIf you could change two things‚ÄĚ question I have been asking interviewees for nearly ten years.

SPaMCAST 391 will feature our top downloaded podcasts from the years of 2007 and 2008:

SPaMCAST 2 ‚Äď Will McKnight on Process and Product Quality Assurance

http://bit.ly/1VBujvS

Will used his wishes to talk about the need for an organizational process focus and the guidance to sustain process improvement.

SPaMCAST 4 - Stasia Iwanicki on Six Sigma

http://bit.ly/1WdJnOP

Stasia used her first wish to address requirements capture, development, and management. Her second wish was for better measurement for supporting the software development process.

SPaMCAST 49 ‚Äď Robin Goldsmith on Requirements

http://bit.ly/23ZC9Av

Robin used his wishes to discuss the need to capture and validate the real business requirements which lead to better systems.

If you enjoyed the snippets please use the links to listen to the whole interviews. Next week 2009!

Categories: Process Management

Stand Up Meetings

Preparing for a Daily Stand Up

Preparing for a Daily Stand Up

**The Re-Read of Commitment: A Novel About Managing Project Risk will resume when I get back from vacation in May. In the meantime, please enjoy this rerun.**

__

The daily stand-up meeting is the easiest Agile practice to adopt and the easiest to get wrong.  In order to get it right, we need to understand the basic process and the most common variants. These include interacting with task lists/boards and distributed team members. The basic process is blindingly simple.

  • The team gathers on a daily basis.
  • Each team member answers three basic questions:
    • What tasks did I complete since the last meeting;
    • What tasks do I intend to complete before the next meeting, and
    • What are the issues blocking my progress.
  • The meeting ends, team members return to work OR discuss other items.

This is the barest bones version of a stand-up meeting.  The meeting is typically attended by the whole team; which includes the scrum master/coach, the product owner and all other team members.  Arguably while the product owner is not a required participant based on the published Scrum guidelines, their central role makes them an important contributor to the meeting when questions about direction come up. I advise team members to discuss whether the product owner will participate (highly recommended) when they develop the Agile team charter and add participation to the team norms.

The most common process addition is the inclusion of a task list/board, either as a physical list often found on the wall of a team room or virtually through the use of a software tool. The team will use the board to guide the discussion.  The tasks they talk about should be on the wall or in the tool.  Sometimes teams adopt a rule that the team members do not work on items not on the wall (or tool). The task list focuses the team and provides visual feedback as tasks change status.

  • You will need to add the following steps to the process when using a list or board:
  • Ensure that all participants can see and interact with the list during the stand-up and throughout the day.
  • Update the board or tool in as close to real time as possible.

Lists and boards can get out of sync with reality.  Out-of-sync tools deliver bad information and can lead to work failing through the cracks.  When tools or task list are used they must be kept up to-date. Each team member must keep his or her tasks up-to-date.  This is not the scrum master/coaches role; they are not project administrators.

Distributed Teams

Distributed teams, teams where one or more team members are in a different location, present several challenges, including time zones, accents, organization affiliation and sometimes language. In general, the stand-up meeting should be basically the same, regardless of the participant’s location. Typically, what does change are the tools needed to make the meeting effective. Videoconference or good teleconference equipment is an absolute must, as is access to the task list (a virtual tool is useful).

You will need to add the following steps to the process when the team is distributed:

  • Ensure that everyone on the team can see and hear each other.¬† This typically means securing or scheduling video or teleconferencing facilities.
  • Ensure that all participants can see and interact with the list during the stand-up and throughout the day.
  • Update the board or tool in as close to real time as possible.

Techniques that are effective making daily stand-ups work for distributed teams include:

  • Deal with the time zone issue. There are two primary options to deal with time zones. The first is to keep the team members within three or four time zones of each other. Given typical sourcing options, this tends to be difficult. A second option is to rotate the time for the stand-up meeting from sprint to sprint so that everyone loses a similar amount of sleep (share the pain option). One usable solution that can be tried when distributed teams can‚Äôt overlap is to have one team member (rotate) staying late or coming in early to overlap work times.
  • Identify and attack blockers between stand-ups. Typically, on distributed teams, all parties will not work at the same time. Team members should be counseled to communicate blockers to the team as soon as they are discovered so that something discovered late in the day in one time zone does not affect the team in a different time zone that might just be starting to work. One group I worked with had stand-ups twice each day (at the beginning of the day and at the end of the day) to ensure continuous communication.
  • Push status outside the stand-up. A solution suggested by Matt Hauser is to have the team answer the classic three questions (What did you do yesterday? What will you do today? Is there anything blocking your progress?) on a WIKI for everyone on the team to read before the stand-up meeting. This helps focus the meeting on planning or dealing with issues.
  • Vary the question set being asked. The process of varying the question set keeps the team focused on communication rather than giving a memorized speech. This technique can be used for non-distributed teams as well as distributed teams. For example ask:
    • Is anyone stuck?
    • Does anyone need help?
    • What did not get competed yesterday?
    • Is there anything everyone should know?
  • Ensure that everyone is standing. This is code for making sure that everyone is paying attention and staying focused. Standing is just one technique for helping team members stay focused. Other tips include banning cell phones and side conversations.
  • Make sure the meeting stays ‚Äúcrisp.‚ÄĚ Stand-up meetings by definition are short and to the point. The team needs to ensure that the meeting stays as disciplined as possible. All team members should show up on time and be prepared to discuss their role in the project. Discussion includes the willingness to ask for help and to provide help to team members.
  • Use a physical status wall. While the term ‚Äúdistributed‚ÄĚ screams tool usage, using a physical wall helps to focus the team. The simplicity of a physical wall takes the complexity of tool usage off the table so the focus can be on communication. Use of a physical wall in a distributed environment will mean using video to moving tasks on the wall (after the fact a picture can be provided to the team). If video is not available, use a tool that EVERYONE has access to. Keep tools as simple as possible.
  • Don‚Äôt stop doing stand-ups. Stand-up meetings are a critical communication and planning event, not doing stand-ups for a distributed team is an indicator that the organization should go back to project manager/plan-based methods.
  • Like any other distributed team meeting, having good telecommunication/video tools is not only important, it is a prerequisite. If team members can‚Äôt hear each other, they CAN‚ÄôT communicate.

The stand-up meeting is a simple meeting that Agile teams hold on a daily basis to plan and synchronize activities.  Adding lists and tools can make the meeting more effective by focusing team effort, BUT adding lists and tools means that the team needs to keep them up to date and use them!  If we add complications such as distributing the team, virtual tools become a necessity. I have had to ask more than one team what value they were getting from a stand-up if part of the team couldn’t hear and participate.


Categories: Process Management

Metrics:  5 Productivity Usage and Calculation Mistakes

The more complex the door, the lower the 'door' productivity.

The more complex the door, the lower the ‘door’ productivity – but not always.

While productivity is a simple calculation, there are a few mistakes organizations tend to make.  The five most common mistakes reduce the usefulness of measuring productivity, or worse can cause organizations to make poor decisions based on bad numbers.  The five most common usage and calculation mistakes are:

1.      Calculating productivity using inputs as outputs.  Productivity is the ratio of output created per unit of input.  For example, if a factory created widgets then labor productivity would be calculated as widgets per hour. A common software productivity metric is function points per person.  Inverting the equation would yield a metric of people per function point which make very little sense.  Solution: Repeat after me, productivity is output divided by input (a bit of snark).  Other metrics use an output as a driver to predict usage of resources.  For example, we calculate delivery rate (answers how fast the process delivers) by dividing calendar time by output.

2.      Using aggregate or average productivity for concrete planning. Productivity averages are often a useful tool for portfolio planning. Portfolio planning occurs when organizations know few of the details about a piece of work.  Solution: In software development and maintenance, never use an organization-level productivity number to set specific goals for a project, sprint or feature.    

3.      Labor productivity is a loose proxy measure for some types of change.  Not all process improvements have a direct impact on labor productivity.  For example, Total Factor Productivity (TFP) would be a better measure to assess the impact of the adoption of Scrum. While we may see the echoes of the of changes in labor or capital productivity, we would be ascribing the impact to the wrong factors which could lead us to try other changes that may not have positive impacts. Solution: Most software development and maintenance organizations will not spend the time and effort needed to measure TFP. Continue using labor or capital productivity to evaluate changes, but in addition evaluate how directly the productivity measures the change.  Understanding how closely the proxy tracks the changes will help the analyst judge the change or alert him or her to search for other impacts.  

4.      Productivity may only be loosely tied to delivered value. Productivity is a measure of raw, non-defective output, not whether that output useful or sellable.  If a software team delivers a product that does not hit the mark or is not adopted in the marketplace, they may have been highly efficient even though their output is less valuable than anticipated.  Solution: Measure both value and productivity to provide a complete view of performance.

5.      Comparing productivity across teams undervalues technical complexity. One piece of software is often significantly more or less complex than another.  Technical complexity often varies not only between applications but within sections of code inside applications.  The more complex the code or business problem, the lower the productivity (complexity increases the amount of effort needed to create an output).  Solution: Each application should evaluate and determine its own productivity based on measuring delivered results. When teams use productivity as a planning tool they should tune the anticipated performance based on the predicted level of technical and business complexity.

Faster, better, cheaper has been the mantra of many a CFO and CIO.  Understanding and improving productivity is one of the tools available to improve performance.  In order to effectively use productivity as a tool, we need to make sure we calculate it correctly and understand that the metric provides a single point of view.  Productivity is a measure  of how effectively an organization transforms inputs into outputs; no more, no less. Productivity metrics provide the most value when coupled with other metrics such as value, speed, and complexity to generate a holistic view of the value delivery chain. 


Categories: Process Management

Software Development Linkopedia April 2016

From the Editor of Methods & Tools - Wed, 04/20/2016 - 09:07
Here is our monthly selection of knowledge on programming, software testing and project management. This month you will find some interesting information and opinions about scaling Agile, Test-Driven Development, recruiting developers, managing technical debt, distributed teams, breaking the rules, test automation, Agile metrics and machine learning. Web site: Agile Scaling Knowledgebase Blog: What do you […]

Metrics: 5 Behaviors Caused By Improper Productivity Measurement

Kafka Statue

Are you measuring a team effort?

Productivity is used to evaluate how efficiently an organization converts inputs into outputs.  However, productivity measures can and often are misapplied for a variety of reasons ranging from simple misunderstanding to gaming the system. Many misapplications of productivity measurement cause organizational behavior problems both from leaders and employees.  Five of the most common productivity-related behavioral problems are:

  1. Attributing team efforts to individuals.  Most software development and maintenance activities are team efforts. Productivity measures usually reflect the output of the teams doing the work, and can’t be ascribed to an individual.  However, there is often a chronic need to ascribe team output, whether good and bad, to an individual.  For example, often productivity data is used in an individual’s review and evaluation. This can lead to everyone trying to game the metric.  The solution for this issue is just not to fall prey to using a team metric to measure an individual.     
  2. Measuring productivity can reduce productivity.  Measurement of productivity requires time and effort to count the inputs and outputs of a system. If an organization does not measure productivity they could either create more output with the effort they would have used to measure productivity or reduce payroll, in either case leading to an increasing productivity.  If the measurement of productivity is not directly tied to process improvement or cost avoidance it will have no return on investment. Avoid overhead that does not deliver significant ROI. The solution is to use productivity measures as part of process improvement or cost reduction program.
  3. Gold plating an output to increase productivity.¬† One of the most famous adages in management circles is that ‚Äúyou get what you measure.‚ÄĚ ¬†Holding teams or individuals accountable for productivity¬†above¬†all else will lead to pressure to add features even if not asked for in order to¬†increase the development output.¬† This is often¬†referred to as gold plating. Gold plating leads to delivering more functionality than needed often at the expense of needs that are higher value. ¬†One fix I recommend¬†is¬†measuring productivity, value and customer satisfaction to ensure teams have more than a one-dimensional view of their¬†performance.¬†
  4. Optimizing local processes without regard to the overall system. The focus of any system is to deliver the most value possible and to improve over time.  Maximizing the efficiency of a part of a system may not translate to the whole system becoming more efficient. For example, I recently observed a large organization with multiple software teams that efficiently developed software.  After developing and testing the software, the operations/implementation group performed a review and security testing prior to putting the implementation into production.  The operations team had a six-month backlog.  While waiting for review, two changes in the last month had to be withdrawn because the market need had changed before they ever made it to production. At the same time, a process improvement team was looking at ways to increase development productivity. Making the software development process any more efficient would only exacerbate the implementation group bottleneck.  In the end, the organization reallocated three development teams to support the implementation function in working through the backlog and streamlining the process.  As we identified when in our Re-read Saturday of The Goal, systems only increase output if you improve the throughput of the bottlenecks in the system.
  5. What doesn’t get measured gets overused?¬† Some organizations that focus on measuring productivity get very good at finding and utilizing resources that don‚Äôt influence the input side of the equation.¬† A classic issue is under-reporting of effort in time accounting.¬† For example, many organizations cap salaried employee‚Äôs time entry at 40 hours per week, even though they are often working 60 hours or more. The overtime is effectively hidden and because it considered free. Therefore, there is often little pressure to measure the overtime¬†(until people start¬†quitting).¬† Any resource that¬†is considered free will be¬†overused.

The last two behavioral issues are often the most common and can occur even when organizations don’t explicitly measure productivity. Every organization, whether they explicitly measure productivity or not, wants software development to deliver more functionality and cost less.  Organizations that don’t take a systems thinking view  can actually increase cost and reduce real productivity hurting the long term efficiency of the organization when they are trying to have the opposite impact. 


Categories: Process Management

Sprint Planning for Agile Teams That Have Lots of Interruptions

Mike Cohn's Blog - Tue, 04/19/2016 - 15:00

Many teams have at least a moderate ability to plan and control their time. They're able to say, "We will work on these things over the coming sprint," and have a somewhat reasonable expectation of that being the case.

And that's the type of team we encounter in much of the Scrum literature--the literature that says to plan a sprint and keep change out.

But what should teams do when change cannot be kept out of a sprint?

In this post, I want to address this topic for two different types of teams:

  • A team that has occasional, but not excessive, interruptions
  • A team that is highly interrupt-driven
Planning with a Moderate Margin of Safety

Many teams will benefit from including a moderate amount of safety into each sprint. Basically, these teams should not assume they can keep all changes out of the sprint. For example, a team might want to leave room when planning a sprint for things like:

  • Fixing critical operational issues, such as a server going down
  • Fixing high-severity bugs
  • Doing first- or second-level tech support

There could be many other similar examples. Consider your own environment. You want to try to set a high threshold for what constitutes a worthy interruption to a sprint. Teams really do best when they have large blocks of dedicated time that will not be interrupted.

To accommodate work like this, all a team needs to do is leave a bit of buffer when planning the sprint. Let’s see how that works.

The Three Things That Must Go into Each Sprint

I think of a sprint as containing three things: corporate overhead, and plannable and unplanned time. I think of this graphically as shown in Figure 1.

Figure 1:

Corporate overhead is that time that goes towards things like all-company meetings, answering emails from your past project, attending the HR sensitivity training and so on. Some of these activities may be necessary, but in many organizations, they consume a lot of time.

I put Scrum meetings (planning, daily scrum, etc.) in the corporate overhead category as well.

Plannable time is the second thing that goes into a sprint. This is the time that belongs collectively to the team.

But the team does not want to fill the entire remainder of the sprint with plannable time. The team needs to acknowledge the need to leave room for some amount of unplanned time.

Unplanned time goes towards three things:

  • Emergencies
  • Tasks that will get bigger than the team thinks
  • Tasks that no one thinks of during the sprint planning meeting
The Appropriate Percentages

I’m frequently asked what percentages teams should use for each of the three categories. I can’t answer that. But I can tell you how to figure it out:

After each sprint, consider how well the unplanned time the team allocated matched the unplanned time the team needed for the sprint. And then adjust up or down a bit for the next sprint. This is not something a team can ever get perfect.

Instead, it’s a game of averages. The team needs to save the right amount of time for unplanned tasks on average. Then some sprints will have more unplanned tasks occur and some sprints will have fewer.

When fewer occur, the team should get ahead on their work. so they’re prepared for when more unplanned tasks occur.

What to Do When a Team Is Highly Interrupt-Driven

The preceding advice works well for the majority of agile teams--those that are only interrupted a moderate amount. Some teams, however, are highly interrupt-driven.

Again, I want to resist putting actual percentages on the regions in Figure 1, but I’m describing a situation in which the area of “unplanned time” becomes much larger than shown.

I actually want to talk about the cases in which unplanned time becomes the dominant of the three areas. Such teams are highly interrupt-driven.

These teams still want to include space in their sprints for unplanned time. But there are usually a few other things you may want to consider if you are on a highly interrupt-driven team.

First, you may want to adjust your sprint length. One option is to go with a long sprint length. Increasing sprint length has the benefit of making the rate of interruption more predictable because the variance will not be so great from sprint to sprint.

To see how that works, imagine you chose a one-year sprint. (Don’t do that!) It’s easy to imagine with such long sprints, the fluctuations a team faces with short sprints will wash out. Sure, this year (this sprint) might have more interruptions than last year (last sprint), but it’s such a long period that the team has time to recover from any excessive fluctuations.

The other option is to go with short, one-week sprints and just live with the unpredictability. The team will be less able to assure bosses “we will be done with this” by a given period, but I find that to be a worthwhile tradeoff.

Second, a highly interrupt-driven team should make sprint planning a very lightweight activity.

Sprint planning should be a quick effort to grab a few things the team thinks it can do in the coming week, and that’s that. It should be a very minimal effort--15 or 30 minutes for many teams.

To illustrate this, think about planning a party, and imagine a spectrum with planning a wedding reception on one end. That’s some serious party planning. At the other end of the spectrum is inviting some friends over tonight to watch the big game on TV. To plan that, I’m going to check the fridge for beer and order a pizza. That’s a different level of party planning.

Sprint planning for a highly interrupt-driven team should be much more like the latter--quick, easy and just enough to be successful.

What Do You Do?

How do you handle interruptions on your agile team? Please share your thoughts in the comments below.

Experimenteren kun je leren

Xebia Blog - Mon, 04/18/2016 - 17:04

pdcaValidated learning: het leren door een initieel idee uit te voeren en daarna de resultaten te meten. Deze manier van experimenteren is de primaire filosofie achter Lean Startup en veel van het Agile gedachtegoed zoals het op dit moment wordt toegepast.

In wendbare organisaties moet je experimenteren om te kunnen voldoen aan de veranderende markt behoefte. Een goed experiment kan ongelooflijk waardevol zijn, mits goed uitgevoerd. En hier zit meteen een veel voorkomend probleem: het experiment wordt niet goed afgerond. Er wordt wel een proef gedaan, maar daar zit vaak geen goede hypothese achter en de lessen worden niet of nauwelijks meegenomen. Ik heb gemerkt dat, om een hoger lerend vermogen in de organisatie te krijgen, het handig om een vaste structuur aan te houden voor experimenten.

Er zijn veel structuren die goed werken. Toyota (of Kanban) Kata vind ik persoonlijk heel erg fijn, maar ook de ‚Äúgewone‚ÄĚ Plan-Do-Check-Act werkt erg goed. Die structuur voor een staat met een simpel voorbeeld hieronder uitgelegd:

  1. Hypothese

Welk probleem ga je oplossen? En hoe wil je dat gaan doen?

Als het hele team vanuit huis inbelt voor de stand up dan worden we niet minder effectief dan als iedereen aanwezig is en kunnen we beter omgaan met thuiswerkdagen

  1. Voorspelling van de uitkomsten

Wat is je verwachting van de uitkomsten? Wat ga je zien?

Geen lagere productiviteit, hogere score op team happiness omdat mensen vanuit huis kunnen werken

  1. Experiment

Op welke manier ga je toetsen of je het probleem kunt oplossen? Is dit experiment ook safe to fail?

De komende zes weken belt iedereen in vanuit huis voor de stand up. We scoren in de retrospective op productiviteit en happiness. Daarna doen we zes weken de stand up samen op kantoor

  1. Observaties

Verzamel zo veel mogelijk data tijdens je experiment. Wat zie je gebeuren?

Het opzetten van de call duurt erg lang (10-15 minuten). Het is lastig iedereen aan het woord te laten. Bij het inbellen kunnen we het gewone board niet gebruiken omdat niemand post-its kan verhangen.

A well designed experiment is as likely to fail as it is to succeed ‚Äď Free to Don¬†Reinertsen

 Dit is vast niet het beste experiment dat geformuleerd kan worden. Maar daar gaat het niet om. Waar het om gaat is dat het leerproces ontstaat bij de verschillen tussen de voorspelling en de observaties. Het is dus belangrijk om allebei deze stappen te doen en bewust stil te staan bij het leerproces wat daarop volgt. Op basis van je observaties kun je een nieuw experiment formuleren voor nieuwe verbeteringen.

Hoe doe jij je experimenten? Ik ben benieuwd naar wat goed werkt in jouw organisatie.

 

Experimenteren kun je leren

Xebia Blog - Mon, 04/18/2016 - 17:04

pdcaValidated learning: het leren door een initieel idee uit te voeren en daarna de resultaten te meten. Deze manier van experimenteren is de primaire filosofie achter Lean Startup en veel van het Agile gedachtegoed zoals het op dit moment wordt toegepast.

In wendbare organisaties moet je experimenteren om te kunnen voldoen aan de veranderende markt behoefte. Een goed experiment kan ongelooflijk waardevol zijn, mits goed uitgevoerd. En hier zit meteen een veel voorkomend probleem: het experiment wordt niet goed afgerond. Er wordt wel een proef gedaan, maar daar zit vaak geen goede hypothese achter en de lessen worden niet of nauwelijks meegenomen. Ik heb gemerkt dat, om een hoger lerend vermogen in de organisatie te krijgen, het handig om een vaste structuur aan te houden voor experimenten.

Er zijn veel structuren die goed werken. Toyota (of Kanban) Kata vind ik persoonlijk heel erg fijn, maar ook de ‚Äúgewone‚ÄĚ Plan-Do-Check-Act werkt erg goed. Die structuur voor een staat met een simpel voorbeeld hieronder uitgelegd:

  1. Hypothese

Welk probleem ga je oplossen? En hoe wil je dat gaan doen?

Als het hele team vanuit huis inbelt voor de stand up dan worden we niet minder effectief dan als iedereen aanwezig is en kunnen we beter omgaan met thuiswerkdagen

  1. Voorspelling van de uitkomsten

Wat is je verwachting van de uitkomsten? Wat ga je zien?

Geen lagere productiviteit, hogere score op team happiness omdat mensen vanuit huis kunnen werken

  1. Experiment

Op welke manier ga je toetsen of je het probleem kunt oplossen? Is dit experiment ook safe to fail?

De komende zes weken belt iedereen in vanuit huis voor de stand up. We scoren in de retrospective op productiviteit en happiness. Daarna doen we zes weken de stand up samen op kantoor

  1. Observaties

Verzamel zo veel mogelijk data tijdens je experiment. Wat zie je gebeuren?

Het opzetten van de call duurt erg lang (10-15 minuten). Het is lastig iedereen aan het woord te laten. Bij het inbellen kunnen we het gewone board niet gebruiken omdat niemand post-its kan verhangen.

A well designed experiment is as likely to fail as it is to succeed ‚Äď Free to Don¬†Reinertsen

 Dit is vast niet het beste experiment dat geformuleerd kan worden. Maar daar gaat het niet om. Waar het om gaat is dat het leerproces ontstaat bij de verschillen tussen de voorspelling en de observaties. Het is dus belangrijk om allebei deze stappen te doen en bewust stil te staan bij het leerproces wat daarop volgt. Op basis van je observaties kun je een nieuw experiment formuleren voor nieuwe verbeteringen.

Hoe doe jij je experimenten? Ik ben benieuwd naar wat goed werkt in jouw organisatie.

 

SPaMCAST 390 ‚Äď Vinay Patankar, Agile Value and Lean Start-ups

SPaMCAST Logo

http://www.spamcast.net

Listen Now

Subscribe on iTunes

The Software Process and Measurement Cast 390 features our interview with Vinay Patankar.  We discussed his start up Process Street and the path Vinay and his partner took in order to embrace agile because it delivered value, not just because it was cool.  We also discussed how Agile fits or helps in a lean start-up and the lessons Vinay wants to pass on to others.

Vinay’s Bio:

Vinay Patankar is the co-founder and CEO of Process Street, the simplest way to manage your teams recurring processes and workflows. Easily set up new clients, onboard employees and manage content publishing with Process Street.

Process Street is a venture-backed SaaS company and AngelPad alum with numerous fortune 500 clients.

When not running Process Street, Vinay loves to travel and spent 4 years as a digital nomad roaming the globe running different internet businesses. He enjoys food, fitness and talking shop.

Twitter: @vinayp10

Re-Read Saturday News

We continue the read Commitment ‚Äď Novel About Managing Project Risk¬†by¬†Maassen, Matts, and Geary.¬† Buy your copy today and read along (use the link to support the podcast).¬†This week we tackle Chapters Three which explores visualization, knowledge options and focusing on outcomes. Visit the Software Process and Measurement Blog to catchup on past installments of Re-Read Saturday.

Upcoming Events

I will be at the QAI Quest 2016 in Chicago beginning April 18th through April 22nd.  I will be teaching a full day class on Agile Estimation on April 18 and presenting Budgeting, Estimating, Planning and #NoEstimates: They ALL Make Sense for Agile Testing! on Wednesday, April 20th.  Register now!

I will be speaking at the CMMI Institute’s Capability Counts 2016 Conference in Annapolis, Maryland, May 10th and 11th. Register Now!

Next SPaMCAST

The next three weeks will feature mix tapes with the ‚Äúif you could fix two things‚ÄĚ questions from the top downloads of 2007/08, 2009 and 2010.¬† I will be doing a bit of vacationing and all the while researching, writing content and editing new interviews for the sprint to episode 400 and beyond.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: ‚ÄúThis book will prove that software projects should not be a tedious process, for you or your team.‚ÄĚ Support SPaMCAST by buying the book here. Available in English and Chinese.


Categories: Process Management

SPaMCAST 390 ‚Äď Vinay Patankar, Agile Value and Lean Start-ups

Software Process and Measurement Cast - Sun, 04/17/2016 - 22:00

The Software Process and Measurement Cast 390 features our interview with Vinay Patankar. We discussed his start up Process Street and the path Vinay and his partner took in order to embrace agile because it delivered value, not just because it was cool. We also discussed how Agile fits or helps in a lean start-up and the lessons Vinay wants to pass on to others.

Vinay’s Bio:

Vinay Patankar is the co-founder and CEO of Process Street, the simplest way to manage your teams recurring processes and workflows. Easily set up new clients, onboard employees and manage content publishing with Process Street.

Process Street is a venture-backed SaaS company and AngelPad alum with numerous fortune 500 clients.

When not running Process Street, Vinay loves to travel and spent 4 years as a digital nomad roaming the globe running different internet businesses. He enjoys food, fitness and talking shop.

Twitter: @vinayp10

Re-Read Saturday News

We continue the read Commitment ‚Äď Novel About Managing Project Risk by Maassen, Matts, and Geary. Buy your copy today and read along (use the link to support the podcast). This week we tackle Chapters Three which explores visualization, knowledge options and focusing on outcomes. Visit the Software Process and Measurement Blog to catch up on past installments of Re-Read Saturday.

Upcoming Events

I will be at the QAI Quest 2016 in Chicago beginning April 18th through April 22nd. I will be teaching a full day class on Agile Estimation on April 18 and presenting Budgeting, Estimating, Planning and #NoEstimates: They ALL Make Sense for Agile Testing! on Wednesday, April 20th. Register now!

I will be speaking at the CMMI Institute’s Capability Counts 2016 Conference in Annapolis, Maryland, May 10th and 11th. Register Now!

Next SPaMCAST

The next three weeks will feature mix tapes with the ‚Äúif you could fix two things‚ÄĚ questions from the top downloads of 2007/08, 2009 and 2010. I will be doing a bit of vacationing and all the while researching, writing content and editing new interviews for the sprint to episode 400 and beyond.

 

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: ‚ÄúThis book will prove that software projects should not be a tedious process, for you or your team.‚ÄĚ Support SPaMCAST by buying the book here. Available in English and Chinese.

Categories: Process Management

Re-Read Saturday: Commitment ‚Äď Novel about Managing Project Risk, Part 2

Picture of the book cover


This week we continue the read¬†of¬†Commitment¬†‚ÄstNovel about Managing Project¬†Risk¬†by¬†Olav Maassen, Chris Matts and Chris Geary (2nd edition, 2016)¬†with¬†chapter 3.¬† Chapter 3 introduces a number of Agile and lean techniques.¬† Susan follows the path of the hero as she crosses the threshold into a new world, signifying her commitment to the journey, and she begins to identify allies.

As a reminder, Chapter 2 ended with the management team telling Rose that the plan she presented was no different from the one David had presented.  Management fired David after presenting his plan to complete the project. The management committee is ready to shut down the project and terminate the lot.  Chapter 3 begins with Rose’s cry for help to Lily. Lily listens and convinces Rose to ask for help from the mentors. She finally calls the number on the business card Lily gave her in chapter 1 to set up a meeting with a mentor. As Rose is leaving the office (with everyone laboring into the evening) to go to the meeting with a mentor at the Cantina of Learning, no one even says goodbye. Rose is a pariah even to her own team.

There’s a call out in one of Lily’s blogs that describes the knowledge options and relationships as the transition from Rose‚Äôs leaving work and getting to the Cantina of Learning. Knowledge options are where you know¬†just enough about a subject to know how to apply the subject and how long it will take to get up to speed on the topic when needed. With this knowledge, a practitioner can assess a situation, assess his or her options and then commit based on context. There’s an old¬†saying ‚Äúif the only tool you own is a hammer, then everything looks like a nail.‚ÄĚ That is an example of a¬†practitioner not having (or understanding that there are) knowledge options. Having knowledge options allows individuals and teams to pivot at the last possible moment when the option has the highest value. Knowledge options help you make decisions with the best possible knowledge, which will improve the outcome of the decision. Knowledge options are an acknowledgment that being consciously incompetent has value if you know how long it takes to move from consciously incompetent to consciously competent. For example, if a new piece of functionality required learning Ruby and that it would take two months of study to become proficient you would be able to decide when the piece¬†of work could be done based on your capability in Ruby. ¬†¬†

The blog entry goes on further to provide advice on finding the right mentor. The advice is to find an author that has published a good book on the subject and then identify the community that generally exists around the author’s work. The practitioners that are active in the community often have the time and experience to act as mentors. I use a variant of this process to find and engage people for Software Process and Measurement Cast interviews.

Once Rose is ensconced in the Cantina of Learning,¬†the journey to redemption begins. Rose meets Jon who tells Rose about work visualization and stand-ups.¬† Visualization helps the team know where they are and how they can coordinate their own activities. The process of visualizing the flow of work identifies all the work in process (WIP).¬† A side benefit of identifying WIP¬†is that you can see¬†when a person is working on more than one piece of work at a time. ¬†WOrking on more than one thing at a time is multitasking. Multitasking actually hides work sitting in queue (waiting). ¬†Work that is sitting slows the process of delivery. Rose’s role is to help unblock tasks and to find and break dependencies between tasks.¬† Dependencies are blockages waiting to happen. Visualization is perhaps one of the most basic techniques in Agile and lean.¬† When work is visualized teams can self-organize and self-manage.¬† The value of visualizing work is huge; however, the urgency around the concept has waned as tools have replaced card walls and paper Kanban board which reduces the effectiveness of the technique.

The chapter’s action culminates with Jon introducing Rose¬†to Liz. ¬†Liz builds on visualization by reinforcing the ideas behind real options.¬† Liz points out that each option has three possible solutions.¬† Using options as the decision process is a tool to manage uncertainty. The three possible solutions are:

  1. Postpone the decision and collect more information.
  2. Choose the option that’s easiest to change.
  3. Invest in a different approach that allows change to be easier.

There is no one, best solution.  Projects use all three solutions to maximize value based on the context.  Visualization provides a platform for the team to know where work is in the development life cycle.  The use of options to evaluate generate alternate paths for a decision reduces uncertainty. The combination of these tools gives the project the power to change direction quickly to maximize the value it can deliver. It is important that decisions are made consciously, which means examining each decision with an eye to which option you intend to exercise. 

In order to use the new tools, Susan realizes she needs a coach.  Liz points to a person she knows that happens to be walking the table by as the type of person that she should hire.  It turns out to be Gary, one the leads currently on her team. Gary agrees to act as Rose’s real options coach. 

Chapter 3 ends with Rose writing to Susan and a blog entry from Liz.  The letter introduces the concept of technical debt using the metaphor of a group of roommates that let dishes build up in a dirty kitchen.  After a time, it becomes so hard to clean the kitchen that no one even makes the effort.  Paying down technical debt (refactoring) is important to increase efficiency and makes it easier to respond quickly to change.  Liz’s blog discusses the value of change and reprioritization of the backlog by the customer (or product owner).  The ability to periodically change and reprioritize the backlog is a form of an option. Agile and lean techniques provide a set of tools so the team works on the top priorities, delivers functionality that generates feedback and allows the customer to exercises his/her options by reprioritizing based on functional code.


Categories: Process Management

Re-Read Saturday: Commitment ‚Äď Novel about Managing Project Risk, Part 2

Picture of the book cover


This week we continue the read¬†of¬†Commitment¬†‚ÄstNovel about Managing Project¬†Risk¬†by¬†Olav Maassen, Chris Matts and Chris Geary (2nd edition, 2016)¬†with¬†chapter 3.¬† Chapter 3 introduces a number of Agile and lean techniques.¬† Susan follows the path of the hero as she crosses the threshold into a new world, signifying her commitment to the journey, and she begins to identify allies.

As a reminder, Chapter 2 ended with the management team telling Rose that the plan she presented was no different from the one David had presented.  Management fired David after presenting his plan to complete the project. The management committee is ready to shut down the project and terminate the lot.  Chapter 3 begins with Rose’s cry for help to Lily. Lily listens and convinces Rose to ask for help from the mentors. She finally calls the number on the business card Lily gave her in chapter 1 to set up a meeting with a mentor. As Rose is leaving the office (with everyone laboring into the evening) to go to the meeting with a mentor at the Cantina of Learning, no one even says goodbye. Rose is a pariah even to her own team.

There’s a call out in one of Lily’s blogs that describes the knowledge options and relationships as the transition from Rose‚Äôs leaving work and getting to the Cantina of Learning. Knowledge options are where you know¬†just enough about a subject to know how to apply the subject and how long it will take to get up to speed on the topic when needed. With this knowledge, a practitioner can assess a situation, assess his or her options and then commit based on context. There’s an old¬†saying ‚Äúif the only tool you own is a hammer, then everything looks like a nail.‚ÄĚ That is an example of a¬†practitioner not having (or understanding that there are) knowledge options. Having knowledge options allows individuals and teams to pivot at the last possible moment when the option has the highest value. Knowledge options help you make decisions with the best possible knowledge, which will improve the outcome of the decision. Knowledge options are an acknowledgment that being consciously incompetent has value if you know how long it takes to move from consciously incompetent to consciously competent. For example, if a new piece of functionality required learning Ruby and that it would take two months of study to become proficient you would be able to decide when the piece¬†of work could be done based on your capability in Ruby. ¬†¬†

The blog entry goes on further to provide advice on finding the right mentor. The advice is to find an author that has published a good book on the subject and then identify the community that generally exists around the author’s work. The practitioners that are active in the community often have the time and experience to act as mentors. I use a variant of this process to find and engage people for Software Process and Measurement Cast interviews.

Once Rose is ensconced in the Cantina of Learning,¬†the journey to redemption begins. Rose meets Jon who tells Rose about work visualization and stand-ups.¬† Visualization helps the team know where they are and how they can coordinate their own activities. The process of visualizing the flow of work identifies all the work in process (WIP).¬† A side benefit of identifying WIP¬†is that you can see¬†when a person is working on more than one piece of work at a time. ¬†WOrking on more than one thing at a time is multitasking. Multitasking actually hides work sitting in queue (waiting). ¬†Work that is sitting slows the process of delivery. Rose’s role is to help unblock tasks and to find and break dependencies between tasks.¬† Dependencies are blockages waiting to happen. Visualization is perhaps one of the most basic techniques in Agile and lean.¬† When work is visualized teams can self-organize and self-manage.¬† The value of visualizing work is huge; however, the urgency around the concept has waned as tools have replaced card walls and paper Kanban board which reduces the effectiveness of the technique.

The chapter’s action culminates with Jon introducing Rose¬†to Liz. ¬†Liz builds on visualization by reinforcing the ideas behind real options.¬† Liz points out that each option has three possible solutions.¬† Using options as the decision process is a tool to manage uncertainty. The three possible solutions are:

  1. Postpone the decision and collect more information.
  2. Choose the option that’s easiest to change.
  3. Invest in a different approach that allows change to be easier.

There is no one, best solution.  Projects use all three solutions to maximize value based on the context.  Visualization provides a platform for the team to know where work is in the development life cycle.  The use of options to evaluate generate alternate paths for a decision reduces uncertainty. The combination of these tools gives the project the power to change direction quickly to maximize the value it can deliver. It is important that decisions are made consciously, which means examining each decision with an eye to which option you intend to exercise. 

In order to use the new tools, Susan realizes she needs a coach.  Liz points to a person she knows that happens to be walking the table by as the type of person that she should hire.  It turns out to be Gary, one the leads currently on her team. Gary agrees to act as Rose’s real options coach. 

Chapter 3 ends with Rose writing to Susan and a blog entry from Liz.  The letter introduces the concept of technical debt using the metaphor of a group of roommates that let dishes build up in a dirty kitchen.  After a time, it becomes so hard to clean the kitchen that no one even makes the effort.  Paying down technical debt (refactoring) is important to increase efficiency and makes it easier to respond quickly to change.  Liz’s blog discusses the value of change and reprioritization of the backlog by the customer (or product owner).  The ability to periodically change and reprioritize the backlog is a form of an option. Agile and lean techniques provide a set of tools so the team works on the top priorities, delivers functionality that generates feedback and allows the customer to exercises his/her options by reprioritizing based on functional code.


Categories: Process Management

Metrics: Total Factor Productivity ‚Äď The Really Hard Bit

Not quite a Google bus

Not quite a Google bus

Labor, raw material, and capital productivity are easy concepts to understand.  For example, labor productivity is the ratio of the products delivered per unit of effort.  Increasing the efficiency of labor will either increase the amount of product delivered or reduce the amount of labor needed.  Raw material or capital productivity follow the same pattern. The issue is that while labor, raw materials, and capital explain a lot of the variation in productivity, they do not explain it all. And in software product development other factors often contribute significantly to productivity improvement. Total factor productivity (TFP) is not a simple ratio of output to input, but rather is a measure that captures everything that is not captured as labor, capital or material productivity. Factors included in total factor productivity include attributes such as changes in general knowledge, the use of particular organizational structures, management techniques, or returns on scale. The components in TFP are often the sources of productivity changes in software development. 

Total factor productivity seeks to account for all of the inputs used to create a product leaving a residual impact on productivity that isn’t directly traceable¬†to¬†inputs.¬† Conceptually I find it easier to consider residual as the effect of non-direct inputs. The formula typically to calculate TFP, the Solow residual, is:

Solow residual

Y = Total Output

A = Total Factor Productivity

K = Capital Input

L = Labor Input

(The superscripts are the percentage contribution of capital and labor to productivity).

Calculating TFP is like removing parts of a picture to identify and appreciate what remains. Very, very, very few software development and maintenance organizations take the time to calculate TFP, but everyone involved in managing software development or actively involved in making and assessing change must understand TFP conceptually and the factors that it represents. The factors that comprise TFP are often very effective levers for changing software development and maintenance productivity. Several of factors that contribute to TFP include technological change, general improvements in social well-being, changes in management approaches, and reallocating resources from low productivity endeavors.   Often we can measure the impacts of the changes in these factors in the other types of productivity indirectly.

Technological change.   Most of us have lived through the period governed by Moore’s Law, and even if we did not personally get access to new, faster processor every year we were impacted by the increase of processing power.  Networks became faster and we can find new ideas to solve problems on the internet, which leads to more and more innovation in how work is done, therefore, increasing productivity. Over the years, many in the software measurement field have noted a constant upward drift attributed to more efficient programming languages.  For example, the venerable coding language COBOL, developed in 1959 has continued to evolve (IBM’s current version is COBOL for x/OS ).  Each version made the language more powerful than the version before it. Technological change is a major contributor to productivity improvement in software development and maintenance.

General improvements in social well-being.¬† ¬†These types of changes include factors such as political stability, transportation infrastructure or general improvements in a country or area’s educational system.¬† Several organizations I talk with regularly source work in the Ukraine.¬† During the height of the recently political problems, they saw a significant drop in both amount and quality of functionality delivered.¬† The same people were working on code and everyone was at work, however, the reduction social well-being disrupted productivity. At an organizational level, companies often work hard to improve the social well-being of their employees and families. Google‚Äôs buses to move employees in and out of the core of San Francisco is a reflection of this the need to improve productivity through increased social well-being.

Changes in management approaches.  Why does Scrum typically lead to higher productivity?  The humans on teams are not generally improved nor is the capital or raw materials; however the change in management approach embodied in Scrum provides a basis for higher performance and increased productivity. For example, embracing Scrum as a management structure allows team members to make decisions faster which improves the efficiency of the team.

Reallocating resources from low productivity endeavors. Business Process Management (BPM) and Business Process Reengineering (BPR) are fields that improve work processes.  They represent a field of operations research that optimizes processes by identifying what an organization does efficiently.  Reducing low productivity activities allows organizations to spend money, effort and other resources on delivering the products and services they are efficient at delivering.  This reallocation is one the reasons continuous process improvement is powerful.

TFP measures the impact of all of these factors and others.  Unfortunately measuring by subtraction is far less straightforward than just measuring labor productivity and pretending we have covered all bases. In software development, TFP represents many of the levers that organizations have to influence productivity. However, labor and capital productivity are often used as proxies to measure the impact of these changes.  While the path from a change in management structure may not be direct, we can at least see the ripples caused by the change in other more straightforward measures.  Interpreting the impact of indirect changes requires more careful analysis and often more explanation.

Next: Productivity Gone Wild


Categories: Process Management

Metrics: The Complexities of Productivity ‚Äď Inputs

26096385160_0723a35c74_o

In simplest terms, productivity is the ratio of output per unit of input.

Almost every conversation about change includes a promise of greater productivity.  In simplest terms, productivity is the ratio of output per unit of input.  While the equation is for calculating productivity is straightforward, as we have discussed, deciding on which outputs from an organization or process to count is never straightforward. The decisions on the input side of the equation are often equally contentious.  Three critical decisions shape what measures will be needed to supply the inputs used to calculate productivity.  

Deciding which inputs lead to an output that is important. Arguably, every ounce of effort, raw material  and capital within a company is ultimately needed to deliver the organization’s products and services. Yet while calculating the total labor or capital productivity might be interesting to stockholders, it provides very little value for making process improvements within the organization. Framing the question or decisions is the critical first step for deciding which work leads to an output that we want to measure.  For example, we can use the pencil manufacturer described in the output essay. In order to deliver a pencil to market the overall value chain would include purchasing and logistics for raw materials, personnel functions for hiring, management, manufacturing, warehousing, shipping, research and development, marketing and sales (see Pencil Supply Chain to get a hint of the complexity of the supply chain for raw materials in a simple wooden pencil). If the manufacturer wanted to tune just the labor productivity of the assembly process for classic #2 pencils, the organization would need to only measure a small slice of the overall value chain. It begins with determining the output to measure, which leads to the which inputs to measure.  Begin all productivity exercises with some form of Value Chain Mapping that shows how an organization transforms raw materials into a product and then delivers that product to its customers.  Develop value chains so that the organization can get a full understanding of the process to see how they can generate the greatest possible value for the organization and the customer.  Once you understand the flow, it is far easier to improve the whole or parts.

Which components of overhead should be part of productivity calculations.¬† Overhead represents costs and effort that can‚Äôt be easily traced to an output.¬† Using the pencil manufacturer example, the effort and cost for the maintenance personnel that sweep the plant on a nightly basis or middle and senior management are often considered overhead. Many software development organizations include¬†only direct labor and costs when calculating productivity .¬† Another ‚Äúnormal‚ÄĚ practice is¬†to apply a uniform allocation of overhead to each project.¬† Both of these scenarios can and do cause significant distortions.¬† For example, a troubled project often consumes significant amounts of management time and oversight (more input) than a well-run project requires (less input).¬† More input for the same amount of output yields lower productivity. Allocation is an easy process but it is regressive.¬† Allocation impacts the projects that are least reliant on non-direct labor and cost more than projects that are more reliant.¬† In the scenario where one project implemented an application that leveraged an internal server farm used by several applications while another leveraged the cloud for processing, allocating the server costs across all projects even if they did not use the servers, would distort capital productivity.

Sourcing refers to purchasing work and/or components for a product from an outside vendor. In the scenario where our pencil manufacturer has outsourced forming the wooden pencil barrel to an outside firm labor, productivity would increase because the process would use less internal effort. In this¬†scenario, the increase in raw material will reduce raw material productivity. The question would be whether the improvement in labor productivity is better for the company than a reduction in raw material productivity.¬† In software development, firms often reduce the cost of work while moving labor effort off an organization‚Äôs books, thus obscuring overall productivity.¬† For example, an organization that outsources technical design, coding and development related testing can only measure the labor productivity of the work they retain control over, therefore if they are measuring labor productivity they need to understand that it is only a partial picture.¬† This realization often shifts the data needs from labor to raw materials or capital. The decisions an organization wants to make to focus on the cost of raw materials rather than ‚Äúlabor‚ÄĚ productivity or some combination of the two.

Deciding what to measure is the second step in unwinding the complexity of the productivity equation.  The inputs in the productivity equation are related to outputs and the decisions that will be made with the information. The decision you are going to make based on productivity will guide you to whether you will need to measure effort, cost of raw material, overhead, physical plant or the cost of outsourced work.  Each will tell a different story about the efficiency of the transformation of an input into an output.


Categories: Process Management

Announcing My First Certified Scrum Master Course in Austin

Mike Cohn's Blog - Tue, 04/12/2016 - 15:00

I'm coming to Austin!

I've wanted to offer training courses in Austin for a while, and the time is right. I'll be there for a Certified Scrum Master course on October 3-4, 2016. The course will be at the Doubletree Northwest Austin Arboretum.

We've got an early bird discount running. Register by September 5 and save $100.

Groups of three or more can also save $100 per person. Groups of 10 or more save $200 per person.

The last time I was in Austin, I was walking around downtown and stopped in a little bar because I liked the band I could hear as I walked by.

I sat down, and by the second song, I realized that blues legend Pinetop Perkins was sitting in on piano with the band. He was in his 90s by then and was still amazing to see.

Seeing Pinetop Perkins perform, meeting him and getting his autograph was an amazing experience.

I hope to have just as much fun in Austin this October. And I hope you'll join me for my first public Certified Scrum Master class there.

Where to Next?

I’m looking to add another city or two into my usual rotation. If you have a suggestion, please let me know in the comments below or by emailing us.