JMP

JMP

I use Microsoft Office, many of my clients use large ERP packages and last week I bought a highly functional math package to do data analysis. I would describe all of these as products that are refreshed over time by major and minor releases. As an outsider, the delineation of product and release is both easily recognizable and easily describable. However once you peel back the covers and dive into the inner workings of the typical corporate IT organization (broad definition that includes development, maintenance, support, security and more), how work is grouped and described can often be much more akin to a descent through Dante’s nine circles of hell.   Recently I sat in a conference room in front of a white board and challenged a group to identify how work was grouped and how the groupings related to each other. During the discussion we choose not to discuss the portfolio level within the organization and focus on the deliver functionality. The results followed a path that looked like a simple basic hierarchy running from programs, projects to sprints . . . except for the waterfall teams that don’t do sprints. This hierarchy  was crosscut by products and releases increasing the possible complexity of any particular scenario. As work is grouped together from sprints to program into larger and larger blocks additional layers of control are need to manage risk.

In Agile the smallest grouping of work is the sprint. In a perfect world, a team would accept work into a sprint where each story was independent and intrinsically motivating. Each piece of work would be its own big picture, however that scenario is at best rare. Most people are interested in knowing that they are helping build the Golden Gate Bridge, not just the left lane of a typical bridge on-ramp. We are more motivated when we believe we are doing something big. It is rare that a unit of work being delivered by a single sprint from a single team will require any scaling.

In most organizations, a project represents a grouping of work that most easily recognized. While the concept of a project is under-pressure in some circles (we will explore concepts such #NoProjects later) I haven’t sat next to anyone on plane that doesn’t describe their work as projects whether they are in marketing, sales, accounting, consulting or software. Projects and project accounting is firmly enforced in most organization’s finance and accounting departments. As noted in Projects in Agile, almost every organization has their own definition of a project. Interestingly, I was eating dinner with a group of developers and scrum masters recently when the conversation turned to the definition of project. A sizable group decided that any discrete task could be described as project. A task had a strart and an end and was goal oriented. From a grouping perspective, projects are typically an accumulation of sprints or releases in Agile. In more classic scenarios, a project can be described as one or more release into production. Any project that is more than a single team and a single team will require scaling to afford greater foresight and planning so that the pieces fit together in a coherent whole.

The definition of a release is widely variable. Releases can be subset of a project with functionality pushed to production, test  or into some other environment. Alternately a release could be a group of whole discrete projects that are moved into an environment together. The only common thread in the use of the term release is that it represents movement. Releases, other than in very uncomplicated environments, will always require coordination between development teams and operations, business and potentially customers. The larger and more complex the release, the more planning and coordination will be required.

Programs are groups of related and often inter-related projects or releases that are organized together to achieve a common goal. By definition programs are larger than projects and can be implemented through one or a large number of releases. Because they are larger and therefore more complex, programs typically require additional techniques to ensure foresight, planning and coordination so that all stakeholders understand what is happening and their role in achieving success.

A final grouping of work is around the concept of product. Building from the Software Engineering Institute’s definition of a software product line, a simple definition of a product could a set of related functions that are managed as a whole to satisfy a specific market need. Typically a product is developed through a project or program and is maintained through releases, projects and programs. Products should have a roadmap that provides internal and external customers guidance on the features that the organization intends to develop and deliver over time. Roadmaps are typically more granular in the near term and more speculative as the time horizon recedes.

As work is grouped from smallest to largest; from sprint to program or product added effort is required to organize and coordinate work. Increased levels of planning and coordination require additional tools and techniques in addition to the basics typically found in Scrum or Extreme Programing (XP). In the Agile vernacular, the need to for additional techniques to deal with size, coordination and planning is called scaling.

Longer isn't necessarily better.

Longer isn’t necessarily better.

In Agile, cadence is the number days or weeks in a sprint or release. Stated another way, it is the length of the team’s development cycle. The cadence that a project or organization selects is based on a number of factors that include: criticality, risk and the type of project. As a general rule, once a team or a team of teams has settled on a specific cadence they tend not to vary significantly. While In today’s business environment a plurality of teams and organizations use a two-week sprint cadence, there is often a lot of angst over the finding the exact number of weeks in a sprint any specific team.  Many organizations adopt a standard and take the discussion off the table. With any specified cadence duration, there are typically three complaints: too much overhead, not getting stories done and not being able to commit resources on full-time basis to the work. In almost every case the complaint is coupled with a request to lengthen the duration of the sprint and therefore to slow the cadence.

  1. The sprint structure requires too much overhead: Sprints begin with a planning event and typically complete with both a demonstration and retrospective. Short stand-up meetings occur daily. Some team participants view these events as overhead. Scrum practice and observation of teams strongly suggests that the effort for the Scrum events increase or decrease depending on the length of the sprint. Longer sprints tend to require more planning and lengthier demos and retrospectives.  As a rule I suggest two hours of planning per week and 30 minutes each for the demonstration and retrospective per week in a sprint. Stand-ups should be approximately 15 minutes per day. For example, I would expect to spend 3 hours 45 minutes (2 hours for planning, 30 minutes for demo, 30 minutes for the retrospective and 45 minutes for 3 stand-up meetings) on events in a one-week sprint and 8 hours (4 hours for planning, 1 hour for the demo, 1 hour for the retrospective and 2 hours for 8 stand-up meetings). I have noticed that the effort for sprint events that are more than three weeks long tend to take longer than one would expect (four weeks sometimes being more than twice what is expected). Realistically, sprint size should not significantly affect overhead until you get to sprints duration’s of four weeks or more therefore overhead is not an obstacle to shorter sprints. Remember that in earlier posts we have shown that shorter sprints deliver feedback and value sooner so therefore are preferred all things being equal.
  2. Our stories can’t be completed during the sprint. This is typically not a problem with the duration of sprint, but either an issue of how the stories are split or a process problem. One typical corollary to this complaint is that the team can’t break stories into thin enough slices to complete. Most of the time this is a training or coaching problem rather than a technical problem, however in highly regulated environments or systems that affect human life I have seen scenarios where stories tend to require longer sprints due to very specific variation and validation. One common cause of this problem is assigning and hard wiring roles (testers can only test for example), which can cause bottlenecks and constraints if there is any imbalance in capacity. This is illustrated by the Theory of Constraints (take a look at our Re-read Saturday entries about The Goal for more on the Theory of Constraints). Typically, longer sprints will not solve the problem. Unless the underlying capacity issue is addressed longer sprints typically equate to worse performance because more stories are started and are subject to bottlenecks and constraints.
  3. Our organization can’t commit full-time resources to a sprint. Part-time team members typically have to time slice, switching between projects and pieces of work leading to some loss of efficiency. This is a reflection too much work and not enough capacity causing delays, constraints and bottlenecks. Similar to issue 2 above, typically longer sprints will not solve the problem. Unless the underlying capacity issue is addressed longer sprints typically equate to worse performance for the same reasons as noted above.

Many problems with cadence are either a reflection of process problems that generate overhead or poorly split user stories. For example, teams that do not have a groomed backlog will need to spend more time planning. Some team members see planning as avoidable overhead (the just wing it mentality). Overly large teams tend to have long daily stand-up meetings, again typically seen as overhead. Stories that are not thinly sliced will take longer to complete and have higher propensity to get stuck giving the team a feeling that a longer sprint is better. In almost every case, thinly sliced stories and committing to less work tends to improve the flow of work so that the team can actually deliver more. The duration of the sprint and cadence are usually not the root cause of the team’s problems.

Listen Now

Subscribe on iTunes

This week’s Software Process and Measurement Cast features our interview with Alex Papadimoulis.  Alex is returning to the Software Process and Measurement Cast to discuss Release.  Release is card game about making software inspired by development strategies like Lean, Agile, and DevOps, and classic trick -taking card games. We also circled back to talk about continuous delivery and DevOps; a bit of lagniappe to add to a great interview.

Alex’s Bio:

Alex

Alex is a speaker and writer who is passionate about looking beyond the code to build great software. In addition to founding Inedo – the makers of BuildMaster, the popular continuous delivery platform – Alex also started The Daily WTF, a fun site dedicated to building software the wrong way.

Contact Information:

Email:  apapadimoulis@inedo.com
Twitter: @apapadimoulis
Web: http://inedo.com/
Other Web: http://thedailywtf.com/

Call to action!

We are just completed a re-read John Kotter’s classic Leading Change on the Software Process and Measurement Blog (www.tcagley.wordpress.com) and are in process of choosing the next book for Re-read Saturday.  Please go to the poll and cast your vote by February 15?  Vote now at Software Process and Measurement Blog!

Next SPaMCast

In the next Software Process and Measurement Cast we will feature our essay on commitment.  What is the power of making a commitment? The making and keeping of commitments are core components of professional behavior. The simple definition of a commitment is a promise to perform. Whether Agile or Waterfall, commitments are used to manage software projects. Commitments drive the behavior of individuals, teams and organizations.  Commitments are powerful!

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, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.

 In today’s business environment a plurality of organizations use a two week sprint cadence.

In today’s business environment a plurality of organizations use a two week sprint cadence.

In Agile, cadence is the number days or weeks in a sprint or release. Stated another way, it is the length of the team’s development cycle. In today’s business environment a plurality of organizations use a two week sprint cadence. The cadence that a project or organization selects is based on a number of factors that include: criticality, risk and the type of project.

A ‘critical’ IT project would be crucial, decisive or vital. Projects or any kind of work that can be defined as critical need to be given every change to succeed. Feedback is important for keeping critical projects pointed in the right direction. Projects that are highly important will benefit from gathering feedback early and often. The Agile cycle of planning, demonstrating progress and retrospect-ing is tailor-made to gather feedback and then act on that feedback. A shorter cycle leads to a faster cadence and quicker feedback.

Similarly, projects with higher levels of risk will benefit from faster feedback so that the team and the organization can evaluate whether the risk is being mitigated or whether risk is being converted into reality. Feedback reduces the potential for surprises therefore faster cadences is a good tool for reducing some forms of risk.

The type of project can have an impact on cadence. Projects that include hardware engineering or interfaces with heavyweight approval mechanisms will tend to have slower cadences. For example, a project I was recently asked about required two separate approval board reviews (one regulatory and the second security related). Both took approximately five working days. The length of time required for the reviews was not significantly impacted by the amount of work each group needed to approve. The team adopted a four-week cadence to minimize the potential for downtime while waiting for feedback and to reduce the rework risk of going forward without approval. Maintenance projects, on the other hand, can often leverage Kanban or Scrumban in more of a continuous flow approach (no time box).

Development cadence is not synonymous with release cadence. In many Agile techniques, the sprint cadence and the release cadence do not have to be the same. The Scaled Agile Framework Enterprise (SAFe) makes the point that teams should develop on a cadence, but release on demand. Many teams use a fast development cadence only to release in large chunks (often called releases). When completed work is released often either as a reflection of business need, an artifact in thinking from waterfall development and, in some rare cases, the organization’s operational environment.

Most projects will benefit from faster feedback. Shorter cycles, i.e. faster cadence, are an important tool for generating feedback and reducing risk. A faster cadence is almost always the right answer, unless you really don’t want to know what is happening while you can react.