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

Words Have Power

Remember that the race does not always go to the just; however not running will ensure that you can't win. Don’t let your words keep you from running the race.

Remember that the race does not always go to the just; however not running will ensure that you can’t win. Don’t let your words keep you from running the race.

Words have power,when used correctly — the power to sell ideas, to rally the troops and to provide motivation. Or words can be a tactic signal of resistance to change and an abrogation of responsibility.  In the later set of scenarios, perfectly good words go bad.  I want to highlight three words, which when used to declare that action won’t be taken or as a tool to deny responsibility for taking action, might as well be swear words.  The words, in my opinion, that are the worst offenders are ‘but’, ‘can’t’ and ‘however’.  The use of any of these three words should send up a red flag that a course is being charted to a special process improvement hell for an organization.

‘But’

The ugliest word in the process improvement world, at least in the English language, is ‘but’ (not but with two t’s).  ‘But’ is a fairly innocuous word, so why do I relegate it to such an august spot on my bad words list?  Because the term is usually used to explain why the speaker (even though they know better) can’t or won’t fight for what is right.  As an example, I recently participated in a discussion about involving the business as an equal partner in a project (a fairly typical discussion for an organization that is transitioning to Agile).  Everyone involved thought that the concept was important, made sense and would help the IT department deliver more value to the organization, ‘but’ in their opinion, the business would not be interested in participating.  Not that anyone would actually discuss having the business be involved with them or invite them to the project party.  A quick probe exposed excuses like “but they do not have time, so we won’t ask” and the infamous, “but that isn’t how we do it here.”  All of the reasons why they would not participate were rationalizations, intellectual smoke screens, for not taking the more difficult steps of asking the business to participate in the process of delivering projects.  It was too frightening to ask and risk rejection, or worse yet acceptance, then have to cede informational power through knowledge sharing.  The use of the word ‘but’ is used to negate anything out of ordinary which gives the speaker permission to not get involved in rectifying the problem.  By not working to fix the problem, the consequences belong to someone else.

‘Can’t’

A related negation word is ‘can’t’. ‘Can’t’ is generally a more personal negation word than ‘but.’ Examples of usage include ‘I can’t’ or ‘we can’t’. Generally this bad word is used to explain why someone or some group lacks specific power to take action.  Again like ‘but’, ‘can’t’ is used to negate what the person using the word admits is a good idea.  The use of the term reflects an abrogation of responsibility and shifts the responsibility elsewhere. For example, I was discussing daily standups with a colleague recently.  He told me a story about a team that had stopped doing daily stand-up meetings because the product owner deemed them overhead.  He quoted the Scrum Master as saying, “It is not my fault that we can’t do stand-ups because our product owner doesn’t think meetings are valuable.” In short he is saying, “It isn’t my fault that the team is not in control of how the work is being done.”  The abrogation of responsibility for the consequences of the team’s actions is what makes ‘can’t’ into a bad word in this example.  ‘Can’t’ reinforces the head-trash which steals power from the practitioner that makes it easy to walk away from the struggle to change rather than looking for a way to embrace change.  When you empower someone else to manage your behavior, you are reinforcing your lack of power and reducing your motivation and the motivation of those around you.

‘However’

The third of this unholy trinity of negation words is ‘however’.  The struggle I have with this word is that it can be used insidiously to reflect a false use of logic to cut off debate.  A number of years ago, while reviewing an organization that decided to use Scrum and two-week iterations for projects, I was told, “we started involving the team in planning what was going to be done during the iterations, however they were not getting the work done fast enough, so we decided to tell them what they needed to do each iteration.”  The use of ‘however’ suggests a cause-and-effect relationship that may or may not be true and tends to deflect discussion from the root cause of the problem. The conversation went on for some period of time during which we came to the conclusion that by telling them what to do, the project had actually fared even worse.  What occurred was that the responsibility had been shifted away from poor portfolio planning onto the team’s shoulders.

In past essays I have discussed that our choices sometimes rob us of positional power.  The rationalization of those individual choices acts as an intellectual smokescreen to make us feel better about our lack of power. Rationalization provides a platform to keep a clinical distance from the problem. Rationalization can be a tool to avoid the passion and energy needed to generate change.

All of these unholy words can be used for good, and that it might be useful to have more instructions on how to recognize when they are be used in a bad way. A sort of a field guide to avoid mistaken recognition.  One easy mechanism for recognizing a poor use of ‘but’, ‘can’t’ and ‘however’ is to break the sentence or statement into three parts, everything before the unholy word, the unholy word and then everything after the unholy word.  By looking at the phrase that follows our unholy word all is exposed.  If the phrase rejects or explains why original and perfectly reasonable premise is bat poop crazy, then you have a problem.  I decided to spend some of my ample time in airports collecting observations of some of the negation phrases people use.  Some of shareable the examples I heard included:

  1. I told you so.
  2. It is not my fault.
  3. Just forget it.
  4. We tried that before.
  5. That will take too long.
  6. It doesn’t matter (passive aggressive).
  7. We don’t do it that way.
  8. My manager won’t go for it.

There were others that I heard that can’t be shared, and I am sure there are many other phrases that can be used to lull the listener into thinking that the speaker agrees and then pulls the rug out from the listener.

The use of negation words can be a sign that you are trying to absolve yourself from the risk of action.  I would like to suggest we ban the use of these three process improvement swear words and substitute enabling phrases such as “and while it might be difficult, here is what I am going to do about it.”  Our goal should be to act on problems that are blockers and issues rather than to ignore them or by doing that establishing  their reality by saying grace over them.  In my opinion, acting and failing is a far better course of action than doing nothing at all and putting your head in the sand.  The responsibility to act does not go away but rather affixes more firmly to those who do nothing than to those that are trying to change the world!  When you pretend to not have power you become a victim.  Victims continually cede their personal and positional power to those around them.  Remember that the race does not always go to the just; however not running will ensure that you can’t win. Don’t let your words keep you from running the race.


Categories: Process Management

Splitting User Stories: Alternate Patterns

Too many things going on will lead to less attention to anyone subject.

Too many things going on will lead to less attention to anyone subject.

Splitting user stories is an important tool to help teams in a number ways ranging from improving the flow of stories through the development process, to improving the teams understanding of what is required to deliver the story. In almost every case, smaller is better.   We have identified a number techniques for splitting user stories and a framework for evaluating those splits. Additional splitting techniques include:

  1. And/Or Removal: User stories that include “and” or “or” typically reflects compound thoughts. This is an indication that the story is an epic, which will too large to be complete in a single sprint. Split the stories to eliminate instances of “and” and “or“. An example of a story with an “and / or” problem is: As a project manager I want to be able to review and approve time and expenses logged to my projects to ensure accurate reporting and billing. Stories could be constructed separately for reviewing time accounting, approving time accounting, reviewing expenses and approving expenses. Simplicity reduces the potential for confusion.
  2. Simple/Complex: Complexity makes a story harder to complete and therefore the story will take longer to deliver compared to a similarly-sized, simple story. Splitting can be used to isolate functionality that is more or less complex. Splitting based on complexity provides product owners the option of deciding on whether a strategy of doing the simple stories first. This approach could provide teams with insights that reduce the complexity of later stories.
  3. Splitting Non-functional Requirements: Many user stories combine function and non-functional components. For example the story “As a home brewer, I want a conversion calculator that returns results in 40 point type display so that I can determine the alcohol level in the beer.” The story could be split to address the functional side of the story (conversion results) from the non-functional component (size of display). Splitting the story lets team to deliver the calculation before having to address how it is displayed.

These three patterns for splitting user stories (in addition to those noted in previous articles including workflow, business rules, data variations, elementary processes or syntheses of patterns) are just tools for teams. Teams split stories to help them understand what they are committing to deliver, to reduce the complexity of large stories (or at the very least to isolate the hard parts) and so they can enhance their ability to consistently deliver value. Splitting stories increases productivity and quality and reduces the amount of time the team spends scratching their collective heads trying to figure out what they will deliver and how they will deliver.


Categories: Process Management

How to Dockerize your Dropwizard Application

Xebia Blog - Wed, 10/29/2014 - 10:47

If you want to deploy your Dropwizard Application on a Docker server, you can Dockerize your Dropwizard Application. Since a Dropwizard Application is already packaged as an executable Java ARchive file, creating a Docker image for such an application should be easy.

 

In this blog, you will learn how to Dockerize a Dropwizard Application using 4 easy steps.

Before you start

  • You are going to use the Dropwizard-example application, which can be found at the Dropwizard GitHub repository.
  • Additionally you need Docker. I used Boot2Docker to run the Dockerized Dropwizard Application on my laptop. If you use boot2Docker, you may need this Boot2Docker workaround to access your Dockerized Dropwizard application.
  • This blog does not describe how to create Dropwizard applications. The Dropwizard getting started guide provides an excellent starting point if you like to know more about building your own Dropwizard applications.

 

Step 1: create a Dockerfile

You can start with creating a Dockerfile. Docker can automatically build images by reading the instructions described in this file. Your Dockerfile could look like this:

FROM dockerfile/java:openjdk-7-jdk

ADD dropwizard-example-1.0.0.jar /data/dropwizard-example-1.0.0.jar

ADD example.keystore /data/example.keystore

ADD example.yml /data/example.yml

RUN java -jar dropwizard-example-1.0.0.jar db migrate /data/example.yml

CMD java -jar dropwizard-example-1.0.0.jar server /data/example.yml

EXPOSE 8080

 

The Dropwizard Application needs a Java Runtime, so you can start from an base image already available at Docker Hub, for example: dockerfile/java:openjdk-7-jdk.

You must add the Dropwizard Application files to the image, using the ADD instruction in your Dockerfile.

Next, simply specify the commands of your Dropwizard Application, which you want to execute during image build and container runtime. In the example above, the db migrate command is executed when the Docker image is build and the server command is executed when you issue a Docker run command to create a running container.

Finally, the EXPOSE instruction tells Docker that your container will listen on the specified port(s) at runtime.

 

Step 2: build the Docker image

Place the Dockerfile and your application files in a directory and execute the Docker build command to build an Docker image.

docker@boot2docker:~$ docker build -t dropwizard/dropwizard-example ~/dropwizard/

 

In the console output you should be able to that the Dropwizard Application db migrate command is executed. If everything is ok, the last line reported informs you that the image is successfully build.

Successfully built dd547483b57b

 

Step 3: run the Docker image

Use the Docker run command to create a container based on the image you have created. If you need to find your image id use the Docker images command to list your images. It should take around 3 seconds to start the Dockerized Dropwizard example application.

Docker run –p 8080:8080 dd547483b57b

Notice that I included the –p option to include a network port binding, which maps 8080 inside the container to port 8080 on the Docker host.  You can verify whether your container is running using the docker ps command.

docker@boot2docker:~$ docker ps

CONTAINER ID        IMAGE                                  COMMAND                CREATED             STATUS              PORTS                    NAMES

3b6fb75adad6        dropwizard/dropwizard-example:latest   "/bin/sh -c 'java -j   3 minutes ago       Up 3 minutes        0.0.0.0:8080->8080/tcp   high_turing

 

  1. Test the application

Now the application is ready for use. You can access the application using your Docker host ip address and the forward port 8080. For example, use the Google Advanced Rest Client App to register “John Doe”.

GoogleRestClient

User Stories: Splitting User Stories and Adding Detail

 

At some point you need to dive into the detail.

At some point you need to dive into the detail.

A user story is a simple statement of need. A common format for a user story is “<persona> <goal> <benefit>”. Typically when a user story is initially formed it is not ready to be developed. Stories can lack detail because they don’t include acceptance criteria, might need additional detail or might to be broken down.

Acceptance criteria provide confirmation that the story does what was intended and can be used to create an acceptance test. They provide additional detail that helps the team develop an understanding of the story. I have found that acceptance criteria also provide an excellent platform for generating the conversations the user story process expects. In a perfect world acceptance criteria would be written when the story is originally developed or during backlog grooming at the latest.

As team members and stakeholders talk about user stories knowledge is generated. The knowledge that is generated can be housed in pictures, notes, wireframes, paper or functional prototypes to name a few tools in the team’s arsenal for generating a conversation and capturing that conversation. These “documents” need to be captured and linked to the story. The one attachment mechanism you do not want rely on in the long term is your memory.

Large user stories, almost by definition, lack detail. Epics (large user stories) need to be broken down so the team can gain a better understanding of the story, so they can complete the story during the sprint. Splitting stories is as a mechanism to expose functional detail. In Splitting User Stories Based on Elementary Processes, we used an example of large time accounting data entry story. The story was:

  • As a time accounting user, I want to maintain my time so that I can account for the work I do.

The story is well formed (it fits the format we are using), but because it is too large and it obscures a lot of important detail. The story could easily be broken down into smaller stories. For example, add time, change time, display time and delete time would be a quick functional split. Once the story is broken down and the new functionality is exposed, acceptance criteria can be generated providing which generate more detail and further even more knowledge (a virtuous cycle).

User stories evolve. In almost all scenarios I have witnessed additional information and knowledge is generated by the team as they split stories, digest acceptance criteria, have conversation, build models, prototypes and designs.


Categories: Process Management

Software Development Conferences Forecast October 2014

From the Editor of Methods & Tools - Tue, 10/28/2014 - 15:00
Here is a list of software development related conferences and events on Agile ( Scrum, Lean, Kanban) software testing and software quality, programming (Java, .NET, JavaScript, Ruby, Python, PHP) and databases (NoSQL, MySQL, etc.) that will take place in the coming weeks and that have media partnerships with the Methods & Tools software development magazine. W-JAX 2014, November 3-7 2014, Munich, Germany Business Technology Days 2014, November 3-6, Munich, Germany QCon San Francisco, November 3-7 2014, San Francisco, USA Exclusive $50 Method & Tools discount with promo code “softdevconf50″ Better Software & Agile Development Conference ...

Commitment-Driven Sprint Planning

Mike Cohn's Blog - Tue, 10/28/2014 - 15:00

There are two primary ways for planning a sprint: velocity-driven sprint planning and commitment-driven sprint planning. In last week’s post, I described velocity-driven planning; so in this week’s, we turn our attention to commitment-driven sprint planning.

A commitment-driven sprint planning meeting involves the product owner, ScrumMaster and all development team members. The product owner brings the top-priority product backlog items into the meeting and describes them to the team, usually starting with an overview of the set of high-priority items.

Select an Item

Following that, team members select a first item to bring into the sprint. This will almost always be the product owner’s top-priority item, but it is possible that the product owner’s top priority has too many open issues.

Ideally, a team should be able to still bring that item into the sprint and resolve the issues early enough in the sprint to complete the item. But, it’s possible that there are so many issues, that the issues are so significant, or that resolving the issues would take so much time (for example, the need to convene a meeting with 25 user representatives) that the product owner’s top priority is skipped.

Tasks and Hours

Having selected a high-priority item, team members discuss the work involved, and identify the tasks that will be necessary to deliver the product backlog item. Either concurrent with identifying the tasks or immediately after they finish doing so, team members roughly estimate the number of hours each task will take.

Do not ask or expect a team to think of every task that will be done during the sprint. Not only is that impossible, it is also unnecessary.

Teams should think of enough of the tasks that they feel they have thought through the work—but it is important to realize that thinking through the work is the real goal of this meeting. Identifying tasks and hours is secondary.

Asking for Commitment

After they’ve identified tasks and roughly estimated the hours for that one product backlog item, the team members ask themselves, “Can we commit to this?”

I find it very important that the team members ask this collectively of themselves rather than having a ScrumMaster ask, “Can you commit to this?” When team members ask, “Can we commit?” they are committing to each other rather than to the ScrumMaster.

I don’t know about you, but my early, pre-Scrum career is littered with broken “commitments” to bosses who asked if I could deliver something while making it clear my answer better be yes.

The ScrumMaster isn’t a boss and shouldn’t create that type of feeling among team members, but the person is called “master” – and it’s better not to risk being perceived as a boss insisting on a commitment.

Coach a team to ask, “Can we commit?” and it’s clear that they are committing to one another, which will likely be a stronger commitment.

Further, by having the team ask themselves, “Can we commit?” it is clear that the answer should be, “Yes we can” or “No we can’t.” When a ScrumMaster asks, “Can you commit?” some team members will properly answer with “we” but others will answer with “I.”

Scrum demands a full-team commitment: If you’re behind, I’ll help, and I know you’ll do the same for me. It’s not “these are my tasks” and “those are yours.”

Repeat with More Stories

If the team agrees they can commit to a product backlog item, they select another item and repeat the process. And so it goes—tasks, hours and commitment—until someone says they cannot commit to the selected product backlog item.

If someone cannot commit, team members will generally discuss the situation and see if someone else is available to help—perhaps a DBA with rudimentary JavaScript skills can help an overwhelmed JavaScript developer.

If not, perhaps that story can be put back on the product backlog but a smaller item can be brought in, or an item that needs less of the skills possessed by the person who could not commit.

No Role for Points or Velocity?

You may have noticed that in the process so far, there has been no role for story points or velocity. Although I still recommend that product backlog items be given quick, high-level estimates in story points, neither story points nor velocity play a role in commitment-driven sprint planning as described so far.

They do, however, play an important role in the final step of a sprint planning meeting.

Sanity Checking the Commitment

Once team members have filled their available time in the sprint, the ScrumMaster can look at the selected product backlog items, sum the story points assigned to each, and share that sum with the team. Team members can then compare it to the average or recent velocity.

Suppose a team with an average velocity of 20 conducts a commitment-driven sprint planning meeting and selects 19 points of work. They’ve done this without knowing the story point values on any of the selected product backlog items.

When their ScrumMaster tells them they’ve just selected 19 points of work and have an average velocity of 19, that team should feel very confident they’ve selected an appropriate amount of work for the sprint.

Suppose instead, though, that the ScrumMaster for this team announces they’ve selected only 11 points of work. They might in that case ask themselves why they were making the work so hard during sprint planning as compared to when they’d earlier estimated the same items in story points.

For example, this may reveal that during sprint planning they’d identified work they’d earlier not thought about, or perhaps had explicitly assumed would not be part of a given story. Or they may discover that the story really is harder than they’d thought when assigning points to it.

Either way, knowing they’d selected 11 yet averaged 20 will help the team know they’ve selected an appropriate amount of work or perhaps make a change to bring more.

Similarly, if the ScrumMaster announces that the team has selected 30 points, 10 more than their average velocity, the team may wonder what they are forgetting to consider. “Why,” they would discuss, “does this work seem so much easier after sprint planning than it did while estimating story points?”

So: story points and velocity do not play a role during the main portion of a commitment-driven sprint planning meeting. But they play the vital role of acting as a sanity check and confirmation of the plan.

It’s a Commitment, Not a Guarantee

It is important that the team’s commitment not be viewed as a guarantee. As Clint Eastwood said in one of his movies, “If you want a guarantee, buy a toaster.”

The team’s commitment is to do its best. I’d like to see them make their commitment perhaps 80 percent of the time. It should be something they take seriously and should make most of that time. That’s needed for the business to gain confidence in what a team says it can deliver.

However, finishing everything they say they will 100 percent of the time should not be the goal. A team forced to finish everything every time will do so—but by reducing what they commit to.

I originally named this approach commitment-driven sprint planning in my Agile Estimating and Planning book; others have taken to calling this “capacity-based planning.” I’m beginning to like the latter term better because of how easily a team’s commitment can be forced into being a guarantee.

User Stories: A Change of Tone and Perspective

Democratization

Democratization

User stories are one of the lightening rod concepts in Agile development because they reflect a shift in tone and perspective. User stories represent a different plan for translating user needs into functional value than that which is found in traditional approaches to software development.

  1. User stories shift the paradigm from writing to talking.

The metaphor of story is used to drive home the point that a user story reflects a conversation in which users and stakeholders describe  their needs as events in their day-to-day world.  Or when they are describing new functionality as extension of their current work narrative. The shift from writing to talking embraces the fluid nature of narrative that may change each time it is told. Stories are generally documented as short statements that require continued conversations to drill down to detail.

  1. User stories shift the tone from contractual to intimate language.

Most requirements processes include a sign-off. Stakeholders from both IT and the business would validate the requirements document and attest that it was accurate and complete. The document and the sign-off represented a contract. User stories begin as high-level statements that provide only the level of detail needed to develop an initial estimate for development. Stories follow a pattern of evolution from high level into more detailed stories based on conversations with and among the stakeholders. Understanding based on the fluidity of stakeholder’s knowledge is nearly the opposite of signed-off requirements documents.

  1. User stories shift the focus from specialization to collaboration.

Learning to write user stories is a simple process. Whether stories are written using informal or formal formats, all stakeholders can easily learn to write user stories. Because of the ease of writing user stories, all stakeholders can be drawn upon to write user stories. When all stakeholders are involved, requirements stop being the sole responsibility of specialists, such as business analysts. Without the need to draw on exclusively on specialists opens the door for all stakeholders to collaborate on developing an understanding of what has to be developed and delivered.

User stories are a tool that democratizes requirements. When Agile is used, user stories shift the basis for developing and maintaining projects from a requirements driven contract. A contract that is typically driven by all of the requirements users can think of because having a conversation that will evolve the requirements will be at best difficult after sign-off. As requirements evolve they are refined and detail is added through adding acceptance criteria, adding supporting documents and/or by splitting users stories.


Categories: Process Management

How to create Java microservices with Dropwizard

Xebia Blog - Mon, 10/27/2014 - 15:10

On Tuesday October 14th the Amsterdam Middleware Meetup experimented with Dropwizard. The idea was to find out what this technology is about, where it could be useful and what the alternatives are. So below I’ll give you an overview of Dropwizard and compare it to Spring Boot.
The Dropwizard website claims:

Dropwizard pulls together stable, mature libraries from the Java ecosystem into a simple, light-weight package that lets you focus on getting things done.

I’ll discuss each of these claims below.

Stable and mature
Dropwizard uses Jetty, Jersey, Jackson and Metrics as its most important frameworks, but also a host of other stuff like Guava, Liquibase and Joda Time. The latest Dropwizard release is version 0.7.1, released on June 20th 2014. It depends on these versions of some core libraries:
Jetty - 9.2.3.v20140905 - May 2014
Jackson - 2.4.1 - June 2014
Jersey - 2.11 - July 2014

The table shows that stable != out-of-date which is fine of course. The versions of core libraries used are recent though. I guess ‘stable’ means libraries with a long history.

Simple
The components of a Dropwizard application are shown below (taken from the tutorial
http://dropwizard.io/getting-started.html):
Dropview components overview

  1. Application (HelloWorldApplication.java): the applications main method, responsible for startup.
  2. Configuration (HelloWorldConfiguration.java) sets configuration for an environment, this is where you may set hostnames for systems the application depends on or set usernames.
  3. Data object (Saying.java).
  4. Resource (HelloWordResource.java): service implementation entry point
  5. Health Check (TemplateHealthCheck.java): runtime tests that show if the application still works.

Light weight
We did some experiments trying to answer the question whether Dropwizard applications are light weight. The table below summarizes some of the sizes of deployments and tools.
Tomcat size 14 mb
Tomcat lib folder size 7 MB
Jetty size 14,6 MB
Jetty in Dropwizard jar: 5,4 MB
Dropwizard tutorial example 10 mb
Dropwizard extended example 20 MB
Dropwizard Hibernate classes in package: 5 MB

A Tomcat or Jetty installation takes about 14 MB, but if you count only the lib folder the size goes down to about 7 MB. The Jetty folder in Dropwizard however is only 5.5 MB. Apparently Dropwizard managed to strip away some code you don’t really need (or is packaged somewhere else, we didn’t look into that).
Building the tutorial results in a 10 MB jar, so if you would run a webapp in its own Tomcat container, switching to Dropwizard saves quite a bit. On the other hand, deployment size isn’t all that important if we’re still talking < 50 MB.
Compared to your default Weblogic install (513 MB, Weblogic-only on OSX) however, savings are humongous (but this is also true when you compare Weblogic to Tomcat or Jetty).

Productivity
We tried to run the build for the tutorial application (dropwizard-example in the dropwizard project on Github). This works fine and takes about 8 seconds using mocks for external connections. One option to explore would be to run tests against a deployed application. What we’re used to is that deploying an application for test takes lots of time and resources, but starting a Dropwizard app is quite cheap. Therefore it would be possible to run an integration test of services at the end of a build. This would be quite hard to do with e.g. Weblogic or Websphere.

Spring boot
Spring boot is interesting, as well as the discussion around the differences between Spring boot and Dropwizard. See https://groups.google.com/forum/#!topic/dropwizard-user/vH1h2PgC8bU

The official Spring boot website says: Spring Boot makes it easy to create stand-alone, production-grade Spring based Applications that can you can "just run". We take an opinionated view of the Spring platform and third-party libraries so you can get started with minimum fuss. Most Spring Boot applications need very little Spring configuration.
It’s good to see a platform change according to new insights, but still, I remember Rod Johnson saying some ten years ago that J2EE was bloated and complex and Spring was the answer. Now it seems we need Spring boot to make Spring simple? Or is it just that we don’t need application servers anymore to divide resources among processes?

Dropwizard and Docker
Finally we experimented with running Dropwizard in a Docker container. This can be done with limited effort because Dropwizard applications have such a small number of dependencies. Thomas Kruitbosch will report on this later.

References
Spring boot: http://projects.spring.io/spring-boot/
Dropwizard: http://dropwizard.io/

SPaMCAST 313 – Initial Backlogs

www.spamcast.net

http://www.spamcast.net

Listen to the Software Process and Measurement Cast now!

SPaMCAST 313 features our essay on developing an initial backlog.  Developing an initial backlog is an important step to get projects going and moving in the right direction. If a project does not start well, it is hard for it to end well.  We will provide techniques to help you begin well!

The essay begins:

Many discussions of Agile techniques begin with the assumption that a backlog has magically appeared on the team’s door step. Anyone that has participated in any form of project, whether related to information technology, operations or physical engineering, knows that requirements don’t grow on trees. They need to be developed before a team can start to satisfy those requirements.  There are three primary ways to gather requirements based on how information is elicited.

Listen to the rest on the Software Process and Measurement Cast!

Call to action!

What are the two books that have most influenced you career (business, technical or philosophical)?  Send the titles to spamcastinfo@gmail.com.  What will we do with this list?  We have two ideas.  First, we will compile a list and publish it on the blog.  Second, we will use the list to drive “Re-read” Saturday. Re-read Saturday is an exciting new feature we will begin in November with a re-read of Leading Change. More on this new feature next week. So feel free to choose you platform and send an email, leave a message on the blog, Facebook or just tweet the list (use hashtag #SPaMCAST)!

Next

SPaMCAST 314 features our interview with Janet Gregory and Lisa Crispin.  We discussed their new book More Agile Testing. Agile testing is evolving at the same rate as Agile or maybe faster! Testing is still critical for delivering business value.  Buy and read the book this week before listening to the interview!

 

The Software Process and Measurement Cast has a sponsor.

As many you know I do at least one webinar for the IT Metrics and Productivity Institute (ITMPI) every year. The ITMPI provides a great service to the IT profession. ITMPI’s mission is to pull together the expertise and educational efforts of the world’s leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. The ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars. The Software Process and Measurement Cast some support if you sign up here. All the revenue our sponsorship generates goes for bandwidth, hosting and new cool equipment to create more and better content for you. Support the SPaMCAST and learn from the ITMPI.

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.


Categories: Process Management

SPaMCAST 313 – Initial Backlogs

Software Process and Measurement Cast - Sun, 10/26/2014 - 22:00

SPaMCAST 313 features our essay on developing an initial backlog.  Developing an initial backlog is an important step to get projects going and moving in the right direction. If a project does not start well, it is hard for it to end well.  We will provide techniques to help you begin well!

The essay begins:

Many discussions of Agile techniques begin with the assumption that a backlog has magically appeared on the team’s door step. Anyone that has participated in any form of project, whether related to information technology, operations or physical engineering, knows that requirements don’t grow on trees. They need to be developed before a team can start to satisfy those requirements.  There are three primary ways to gather requirements based on how information is elicited.

Listen to the rest on the Software Process and Measurement Cast!

Call to action!

What are the two books that have most influenced you career (business, technical or philosophical)?  Send the titles to spamcastinfo@gmail.com.  What will we do with this list?  We have two ideas.  First, we will compile a list and publish it on the blog.  Second, we will use the list to drive “Re-read” Saturday. Re-read Saturday is an exciting new feature we will begin in November with a re-read of Leading Change. More on this new feature next week. So feel free to choose you platform and send an email, leave a message on the blog, Facebook or just tweet the list (use hashtag #SPaMCAST)!

Next

SPaMCAST 314 features our interview with Janet Gregory and Lisa Crispin.  We discussed their new book More Agile Testing. Agile testing is evolving at the same rate as Agile or maybe faster! Testing is still critical for delivering business value.  Buy and read the book this week before listening to the interview!

 

The Software Process and Measurement Cast has a sponsor.

As many you know I do at least one webinar for the IT Metrics and Productivity Institute (ITMPI) every year. The ITMPI provides a great service to the IT profession. ITMPI’s mission is to pull together the expertise and educational efforts of the world’s leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. The ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars. The Software Process and Measurement Cast some support if you sign up here. All the revenue our sponsorship generates goes for bandwidth, hosting and new cool equipment to create more and better content for you. Support the SPaMCAST and learn from the ITMPI.

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.

Categories: Process Management

Agile Concepts: Notes on Scrum of Scrums

The city is a town at scale.

The city is a town at a different scale.

The Scrum of Scrums is a common tool to scale Agile. In many cases the technique works admirably, however as Scrum-based Agile is applied to larger and larger projects, the Scrum of Scrums technique becomes stressed. The most significant issues include:

  1. As the number of Scrum teams involved on a project increases, the number of attendees increase. As the number of attendees that must talk in a meeting increases, the length of the meeting increases. The length of meeting is perfectly correlated to the number of emails sent by participant during the meeting. In other words, it is difficult to hold the attention of participants in larger, long meeting meetings. As projects grow, curtail the active participants to the team Scrum master /representative. In organizations where product owners wish to hold a Scrum of Scrum type meeting make sure those sessions are separated. I have also seen organizations experiment with hierarchies of Scrum of Scrums meetings.
  2. Project Coordination. Both Scrum of Scrum meetings and their cousins, daily stand-up meetings, are coordination and planning meetings. As the project size grows, coordination and planning meetings require greater context (status) to be effective, which can shift the focus towards informational or status meetings thereby reducing the effectiveness of the technique. Large projects need to have a mechanism for sharing context/status outside of planning and coordination meetings. One interesting solution I have observed (for a large program) was a daily program e-newsletter akin to the newsletter large conferences publish daily. I have also seen status wikis used to great effect. Status and news is easily consumed asynchronously therefore meeting time can be avoided.
  3. The Scrum of Scrums meeting infers a hierarchy in Scrum teams that does not exist. Scrum masters become the conduit of information between teams. Team communicate with their Scrum masters, Scrum masters communicate with other Scrum Masters then to the team they are part of and then the cycle reverses. A few years ago I read an article by Mike Cohn that suggested rotating participation. While rotation might impact the consistency, it would send a message that participation is a role rather than a status level.

Scaling Agile requires thought and planning. A Scrum of Scrums that includes product owners and other participants that worked for a handful of teams might need to be tailored when the project grows to include two or three handfuls of teams. Very few human institutions are linearly scalable forever. When using Scrum of Scrums for larger programs scale the technique rather than just moving to a larger conference room.


Categories: Process Management

Agile Concepts: Scaling Agile and the Scrum of Scrums

Don't let conversation wander, or the participants will lose focus (and maybe take a nap).

Don’t let conversation wander, or the participants will lose focus (and maybe take a nap).

In the long run it probably would be possible deliver all projects or releases with a single Agile team. Unfortunately “the long run” and the dynamic business environment are archenemies. Some degree of speed is required to bring the functionality that stakeholders require to market. For larger projects or releases, speed generally requires more than one team and coordination to deliver. Cadence and synchronization are the goals. One of the techniques used to affect synchronization is the Scrum of Scrums.

A Scrum of Scrum is very similar to the daily Scrum (also known as daily stand-up). At a very basic level a representative from each Scrum team gathers and reviews what each team accomplished, what will be done in the next time period and impediments or blockers. At this level the focus tends to be on coordinating challenges between teams. A backlog of the impediments and challenges is generally kept.

The concept of a Scrum of Scrums in theory is simple and to the point. In practice there are generally a few questions that have to ironed out. Questions typically include:

  1. Different frameworks recommend different frequencies. For example, SAFe recommends twice a week, however the Agile Alliance suggests daily. Scrum of Scrums in practice are generally held on a less frequent basis than the daily stand-up. I use attributes such as project criticality, complexity and Agile maturity to help guide frequency decisions. The more critical, complexity or the less mature, the more frequent the Scrum of Scrums.
  2. The Scrum of Scrums is typically attended by each of the Scrum masters from the teams. Alternate practices include having a technical lead attend when group share Scrum masters, having product owners attend as participants or having all team members attend (this last one is a horrible idea). A warning: the larger the number of active participants, the longer the meeting will be and the less likely the participants will stay focused. Remember, just like the daily stand-up, anyone can attend and listen.
  3. Each framework has a role that chairs the Scrum of Scrums. In SAFe, the Release Train Engineer facilitates the meeting, in other frameworks a program manager or lead Scrum master can fill the role. Alternate practices I have observed include rotating facilitation between Scrum masters (tends to lack consistency), having the lead product owner facilitate (they usually have a too much on their plate) or having an IT manager chair (can curtails discussion). While all of these alternatives can work, rotating is the best of a bad lot.
  4. The classic three questions typically dominate any stand-up like meetings: what did I do, what am I going to do and what is in my way. The Scrum of Scrum generally spins the questions towards information that other teams need to know. Alternative meeting content additions I have observed include adding a question about risks, maintaining a team event calendar (business, environment and social) and overall confidence polling. Every addition increases the possibility of increasing the time spent in meetings and content that is not relevant to everyone involved.

The Scrum of Scrums is sort like a league meeting, or as Mike Cohen calls it, “a team of teams.” The technique is a tried and true mechanism for coordinating multiple Agile teams. Like any meeting, conversation can wander away from the goal of coordination. Push any side discussion not on the agenda to “meet afters” (meetings held after the Scrum of Scrums) or other venues. Mentally recite the mantra, “coordination, coordination, coordination” and stay focused on the agenda.


Categories: Process Management

Agile Concepts: Scale Requires Cadence and Synchronization

Bands need to sync up with the beat.

Bands need to sync up with the beat.

In music, cadence is the number of beats in a bar. When I was young I was in a band. Our drummer generally set the cadence with the beat. In classic rock, the cadence was based on four-four time. When anyone of band members slipped out of time they would use the beat to synchronize. Most songs that include solos leverage the beat to re-sync the band when the soloist returns to the melody. Projects with more than one team use sprint cadence and the ceremonies of Scrum or Scaled Agile Framework Enterprise (SAFe) to stay synchronized or to re-resynchronize. Techniques for synchronization include:

  1. Matching cadence. All techniques for intergroup synchronization begin with matching cadences. When projects teams need to act in a coordinate fashion either because the functionality they are creating has to integrate or because teams might have to help each other need to be on the same cycle. Matching cadences allows teams to more easily integrate, plan and demonstrate the overall functionality being developed.
  2. Joint Planning. When teams are on the same cadence, they can plan together. Getting groups in the same room to plan allows cross-coordination and communication. For example, SAFe uses two day planning exercises to synchronize the planning for program intervals. I have also seen and led planning exercises for smaller groups Scrum teams that fall below the scale SAFe should be used (yes . . . you can scale SAFe work with groups smaller than 50 if you know what you are doing).
  3. Joint Builds. In a perfect world all teams in a project would be operating on a single, unbranched code base so that daily builds and tests would expose any inconsistencies. In many organizations teams either have not matured to that level of coordination or have technical constraints that preclude continuous integration. Matching cadence allows teams to get to done at the same time and to integrate at the end of every sprint. Integration provides technical feedback that helps the overall project stay on track.
  4. Joint Demonstrations. Demonstrations are to stakeholders what joint builds are to developers. Joint demonstrations provide feedback to help the overall project stay functionally on track.
  5. Scrum of Scrums. The Scrum of Scrums is the meeting of Scrum masters (the concept can and should be used for product owners also) on a periodic basis during a sprint. SAFe suggest twice a week; I typically suggest starting at twice a week and then more often if significant issues or risks crop up that need to shared and coordinated. When teams use slower cadences I generally recommend having Scrum of Scrums meetings more often to ensure that teams stay coordinated.

Using Agile at scale for work that requires more than one team will require adopting some techniques for coordination. Matching the cadence is the first place to start. Teams with the same cadence start and end sprints at the same time, making it possible to plan and demonstrate together. Joint planning and demonstration makes it easier for everyone to hear the same story at the same time. We often apply the analogy of herding to coordinating large projects, however cadence and other Agile techniques can be as useful as a good cowboy and horse for keeping the herd together.


Categories: Process Management

The Metrics Minute: Velocity

Zoom!

Zoom!

Audio Version:  Software Process and Measurement Cast 119.

Definition:

The simple definition of velocity is the amount of work that is completed in a period of time (typically a sprint). The definition is related to productivity, which is the amount of effort required to complete a unit of work and delivery rate (the speed that the work is completed).  The inclusion of a time box (the sprint) creates a fixed duratio,n which transforms velocity into more of a productivity metric than a speed metric (how much work can be be done in a specific timescale by a specific team). Therefore to truly measure velocity you need to estimate the units of work completed, have a definition of complete and have a time box.

The definition of done in Agile is typically functional code, however I think the definition can be stretched to reflect the terminal deliverable the sprint team has committed to create and based on the definition of done (for example requirements for a sprint team working on requirements or completed test cases in a test sprint) that the team has established.

Many Agile projects use the concept of story points as a metaphor for size or functional code. Note other functional size measures can be just as easily used. Examples in this paper will use story points as a unit of measure.  What is not size however is effort or duration. Effort is an input that is consumed while transforming ideas into functional code. The amount of effort required for the transformation is a reflection of size, complexity and other factors. Duration like effort is consumed by a sprint not created therefore does not measure what is delivered.

Formula

To calculate velocity, simply add up the size estimates of the features (user stories, requirements, backlog items, etc.) successfully delivered in an iteration.  The use of the size estimates allows the team to distinguish between items of differing levels of granularity.  Successfully delivered should equate to the definition of done.

Velocity = Story Points Completed Per Sprint

And:

Average velocity = Average Number of Story Points Per Sprint

The formula becomes more complex if staffing varies between sprints (and potentially less valuable as a predictive measure).  In order to account for variable staffing the velocity formula would have to be modified as follows:

velocity per person = sum (size of completed features in a sprint / number of people) / number of sprints or observations

To be really precise (not necessarily more accurate) we would have to understand the variability of the data as variability would help define level of confidence.  Variability generated by differences in team member capabilities is one of the reasons that predicability is enhanced by team stability. As you can see, the more complex the environmental scenario becomes, the less simple the math must be to describe the scenario.

Uses:

Velocity is used as a tool in project planning and reporting. Velocity is used in planning to predict how much work will be completed in a sprint and in reporting to communicate what has been done.

When used for planning and estimation the team’s velocity is used along with a prioritized set of granular features (e.g., user stories, backlog items, requirements, etc.) that have been sized or estimated.  The team uses these factors to select what can be done in the upcoming sprint. When the sprint is complete the results are used to update velocity for the next sprint. This is a top down estimation process using historical data.

Over a number of sprints velocity can be used both as a macro planning tool (when will will the project be done) and a reporting tool (we planned at this velocity and are delivering at this velocity).

Velocity can be used in all methodologies and because it is team specific, it is agnostic in terms of units of size.

Issues

As with all metrics, velocity has it’s share of issues.

The first is that there is an expectation of team stability inherent in the metric. Velocity is impacted by team size and composition and without collecting additional attributes and correlating these attributes to performance, change is not predictable (except by gut feel or Ouija Board). There should always be notes kept on team size and capability so that you can understand your data over time.

Similarly team dynamics change over time, sometimes radically. Radical changes in  team dynamics will affect velocity. Note shocks to any system of work are apt to create the same issue. Measurement personnel, SCRUM masters and team leaders need to be aware of people’s personalities and how they change over time.

The first time application of velocity requires either historical data of other similar teams and projects or an estimate. In a perfect world a few sprints would be executed and data gathered before expectations are set however generally clients want an idea of if a project will be completed, when it will be completed and the functions that will be delivered along the way.  Estimates of velocity based on the teams knowledge of the past or other crowd sourcing techniques are relatively safe starting points assuming continuos recalibration.

The final issue is the requirement for a good definition of done. Done is a concept that has been driven home in the agile community. To quote Mayank Gupta (http://www.scrumalliance.org/articles/106-definition-of-done-a-reference), “An explicit and concrete definition of done may seem small but it can be the most critical checkpoint of an agile project.”  A concrete definition of done provides the basis for estimating velocity by reducing variability based on features that are in different states of completion.  Done also focuses the team by providing a goal to pursue. Make sure you have a crisp definition of done and recognize how that definition can change from sprint to sprint.

Related Metrics:

Productivity (size / effort)

Delivery Rate (duration / size)

Criticisms:

The first criticism of velocity is that the metric is not comparable between teams and by Inference is not useful as a benchmark. Velocity was conceived as a tool for Scrum Masters and Team Leads to manage and plan individual sprints. There are no overarching set of rules for the metric to enforce standardization therefore one velocity is apt to reflect something different than the next. The criticism is correct but perhaps off the mark. As a team level tool velocity works because it is very easy to use and can be consistent, adding the complexity of standards and rules to make it more organizational will by definition reduce the simplicity and therefore the usefulness at the team level.

A second criticism is that estimates and budgets are typically set early in a projects life.  Team level velocity may well be an unknown until later.  The dichotomy between estimating and planning (or budgeting and estimating for that matter) is often overlooked.  Estimates developed early in a project or in projects with multiple teams require different techniques to generate. In large projects applying team level velocities requires using techniques more akin to portfolio management which add significant levels of overhead. I would suggest that velocity is more valuable as a team planning tool than as a budgeting or estimation tool at a macro level.

A final criticism is that backlog items may not be defined at consistent level of granularity therefore when applied, velocity may deliver inconsistent results. I tend to dismiss this criticism as it is true for any mechanism that relies on relative sizing. Team consistency will help reduce the variability in sizing however all teams should strive to break backlog items into as atomic stories as possible.


Categories: Process Management

Software Development Linkopedia October 2014

From the Editor of Methods & Tools - Wed, 10/22/2014 - 15:04
Here is our monthly selection of interesting knowledge material on programming, software testing and project management.  This month you will find some interesting information and opinions about managing code duplication, product backlog prioritization, engineering management, organizational culture, mobile testing, code reuse and big data. Blog: Practical Guide to Code Clones (Part 1) Blog: Practical Guide to Code Clones (Part 2) Blog: Selecting Backlog Items By Cost of Delay Blog: WIP and Priorities – how to get fast and focused! Blog: 44 engineering management lessons Article: Do’s and Don’ts of Agile Retrospectives Article: Organizational Culture Considerations with Agile Article: ...

Agile Concepts: The Rationale for Longer Cadence

 

Space between has to big enough and no bigger.

Space between has to big enough and no bigger.

Cadence represents a predictable rhythm. The predictability of cadence is crucial for Agile teams to build trust. Trust is built between the team and the organization and  amongst the team members themselves by meeting commitments over and over and over. The power of cadence is important to the team’s well being, therefore the choice of cadence is often debated in new teams. Many young teams make the mistake of choosing a slower (longer) cadence for many reasons. The most often cited reasons I have found are:

  1. The team has not adopted or adapted their development process to the concept of delivering working functionality in a single sprint. When a team leverages a waterfall or remnants of a waterfall method, work passes from phase to phase at sprint boundaries. For example, it passes from coding to testing. Longer time boxes feel appropriate to the team so they can get analysis, design, coding, testing and implementation done before the next sprint. The problem is that they are trying to “agilefy” a non-Agile process, which rarely works well.
  2. New Agile teams tend to lack confidence in their capabilities. Capabilities that teams need to sort out include both learning the techniques of Agile and abilities of the team members. Teams convince themselves that a longer sprint will provide a bit of padding that will accommodate the learning process. The problem with adding padding is twofold. The first is that time tend to fill the available time (Parkinson’s Law) and secondly lengthening the sprint delays retrospectives. Retrospectives provide a team the platform needed to identify issues and make changes which leads to improved capabilities.
  3. Large stories that can’t be completed in a single sprint are often noted as reason to adopt longer duration sprints and slower cadence. This is generally a reflection of improper backlog grooming. More mature Agile teams typically adopt a rule of thumb help guide the breakdown of stories. Examples include maximum size limits (e.g. 8 story points, 7 quick function points) or duration limits (a story must be able to be completed in 3 days).
  4. Planning sessions take too long, eating into development time of the sprint. Similar to the large stories, overly long planning sessions are typically a reflection of either poor backlog grooming or trying to plan and commit to more than can be done within the sprint time box. Teams often change the length of a sprint rather than doing better grooming or taking less work. Often even when the sprint duration is expanded the problem of overly long planning sessions returns as more stories are taken and worsens as the team gets bored with planning.

Teams often think that they can solve process problems by lengthening the duration of their sprints, which slows their cadence. Typically a better solution is to make sure they are practicing Agile techniques rather than trying to “agilefy” a waterfall method or doing a better job grooming stories. A faster cadence is generally better if for no other reason than the team will get to review their approach faster by doing retrospectives!


Categories: Process Management

Velocity-Driven Sprint Planning

Mike Cohn's Blog - Tue, 10/21/2014 - 15:00

There are two general approaches to planning sprints: velocity-driven planning and commitment-driven planning. Over the next three posts, I will describe each approach, and make my case for the one I prefer.

Let’s begin with velocity-driven sprint planning because it’s the easiest to describe. Velocity-driven sprint planning is based on the premise that the amount of work a team will do in the coming sprint is roughly equal to what they’ve done in prior sprints. This is a very valid premise.

This does assume, of course, things such as a constant team size, the team is working on similar work from sprint to sprint, consistent sprint lengths, and so on. Each of these assumptions is generally valid and violations of the assumptions are easily identified—that is, when a sprint changes from 10 to nine working days as in the case of a holiday, the team knows this in advance.

The steps in velocity-driven sprint planning are as follows:

1. Determine the team’s historical average velocity.
2. Select a number of product backlog items equal to that velocity.

Some teams stop there. Others include the additional step of:

3. Identify the tasks involved in the selected user stories and see if it feels like the right amount of work.

And some teams will go even further and:

4. Estimate the tasks and see if the sum of the work is in line with past sprints.

Let’s look in more detail at each of these steps.

Step 1. Select the Team’s Average Velocity

The first step in velocity-driven sprint planning is determining the team’s average velocity. Some agile teams prefer to look only at their most recent velocity. Their logic is that the most recent sprint is the single best indicator of how much will be accomplished in the next sprint. While this is certainly valid, I prefer to look back over a longer period if the team has the data.

I prefer to take the average of the eight most recent sprints. I’ve found that to be fairly predictive of the future. I certainly wouldn’t take the average over the last 10 years. How fast a team was going during the Bush Administration is irrelevant to that team’s velocity today. But, similarly, if you have the data, I don’t think you should look back only one sprint.

Step 2: Select Product Backlog Items

Armed with an average velocity, team members select the top items from the product backlog. They grab items up to or equal to the average velocity.

At this point, velocity-driven planning in the strictest sense is finished. Rather than taking an hour or two per week of the sprint, sprint planning is done in a matter of seconds. As quickly as the team can add up to their average velocity, they’re done.

Step 3: Identify Tasks (Optional)

Most teams who favor velocity-driven sprint planning realize that planning a sprint in a few seconds is probably insufficient. And so many will add in this third step of identifying the tasks to be performed.

To do this, team members discuss each of the product backlog items that have been selected for the sprint and attempt to identify the key steps necessary in delivering each product backlog item. Teams can’t possibly think of everything so they instead make a good faith effort to think of all they can.

After having identified most of the tasks that will ultimately be necessary, team members look at the selected product backlog item and the tasks for each, and decide if the sprint seems full. They may conclude that the sprint is overfilled or insufficiently filled and add or drop product backlog items. At this point, some teams are done and they conclude sprint planning with a set of selected product backlog items and a list of the tasks to deliver them. Some teams proceed though to a final step:

Step 4: Estimate the Tasks (Optional)

With a nice list of tasks in front of them, some teams decide to go ahead and estimate those tasks in hours, as an aid in helping them decide if they’ve selected the right amount of work.

In next week’s post, I’ll describe an alternative approach, commitment-driven sprint planning. And after that, I’ll share some recommendations.

Velocity-Driven Sprint Planning

Mike Cohn's Blog - Tue, 10/21/2014 - 15:00

There are two general approaches to planning sprints: velocity-driven planning and commitment-driven planning. Over the next three posts, I will describe each approach, and make my case for the one I prefer.

Let’s begin with velocity-driven sprint planning because it’s the easiest to describe. Velocity-driven sprint planning is based on the premise that the amount of work a team will do in the coming sprint is roughly equal to what they’ve done in prior sprints. This is a very valid premise.

This does assume, of course, things such as a constant team size, the team is working on similar work from sprint to sprint, consistent sprint lengths, and so on. Each of these assumptions is generally valid and violations of the assumptions are easily identified—that is, when a sprint changes from 10 to nine working days as in the case of a holiday, the team knows this in advance.

The steps in velocity-driven sprint planning are as follows:

1. Determine the team’s historical average velocity.
2. Select a number of product backlog items equal to that velocity.

Some teams stop there. Others include the additional step of:

3. Identify the tasks involved in the selected user stories and see if it feels like the right amount of work.

And some teams will go even further and:

4. Estimate the tasks and see if the sum of the work is in line with past sprints.

Let’s look in more detail at each of these steps.

Step 1. Select the Team’s Average Velocity

The first step in velocity-driven sprint planning is determining the team’s average velocity. Some agile teams prefer to look only at their most recent velocity. Their logic is that the most recent sprint is the single best indicator of how much will be accomplished in the next sprint. While this is certainly valid, I prefer to look back over a longer period if the team has the data.

I prefer to take the average of the eight most recent sprints. I’ve found that to be fairly predictive of the future. I certainly wouldn’t take the average over the last 10 years. How fast a team was going during the Bush Administration is irrelevant to that team’s velocity today. But, similarly, if you have the data, I don’t think you should look back only one sprint.

Step 2: Select Product Backlog Items

Armed with an average velocity, team members select the top items from the product backlog. They grab items up to or equal to the average velocity.

At this point, velocity-driven planning in the strictest sense is finished. Rather than taking an hour or two per week of the sprint, sprint planning is done in a matter of seconds. As quickly as the team can add up to their average velocity, they’re done.

Step 3: Identify Tasks (Optional)

Most teams who favor velocity-driven sprint planning realize that planning a sprint in a few seconds is probably insufficient. And so many will add in this third step of identifying the tasks to be performed.

To do this, team members discuss each of the product backlog items that have been selected for the sprint and attempt to identify the key steps necessary in delivering each product backlog item. Teams can’t possibly think of everything so they instead make a good faith effort to think of all they can.

After having identified most of the tasks that will ultimately be necessary, team members look at the selected product backlog item and the tasks for each, and decide if the sprint seems full. They may conclude that the sprint is overfilled or insufficiently filled and add or drop product backlog items. At this point, some teams are done and they conclude sprint planning with a set of selected product backlog items and a list of the tasks to deliver them. Some teams proceed though to a final step:

Step 4: Estimate the Tasks (Optional)

With a nice list of tasks in front of them, some teams decide to go ahead and estimate those tasks in hours, as an aid in helping them decide if they’ve selected the right amount of work.

In next week’s post, I’ll describe an alternative approach, commitment-driven sprint planning. And after that, I’ll share some recommendations.

Agile Concepts: Cadence

 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.


Categories: Process Management

SPaMCAST 312 – Alex Neginsky, A Leader and Practitioner’s View of Agile

www.spamcast.net

http://www.spamcast.net

Listen to the SPaMCAST 312 now!

SPaMCAST 312 features our interview with Alex Neginsky.  Alex is a real leader and practitioner in a real company that has really applied Agile.  Alex shares pragmatic advice about to how practice Agile in the real world!

Alex’s bio:

Alex Neginsky began his career in the software industry at the age of 16 as a Software Engineer for Ultimate Software. He earned his Bachelor’s degree in Computer Science at Florida Atlantic University in 2006. By age 27, Alex obtained his first software patent.

Alex has been at MTech, a division of Newmarket International, since 2011. As the Director of Development he brings 15 years of experience, technical skills, and management capabilities. Alex manages highly skilled software professionals across several teams stationed all over Eastern Europe and the United States. He serves as the liaison between MTech Development and the industry. During his tenure with the MTech division of Newmarket, Alex has been pivotal in the adoption of the complete software development lifecycle and has spearheaded the adoption of leading Agile Development Methodologies such as Scrum and Kanban. This has yielded higher velocity and better efficiencies throughout the organization.

Contact Alex at aneginsky@newmarketinc.com

LinkedIn

If you have the right stuff and are interested in a joining Newmarket then check out:

http://www.newmarketinc.com/careers/join-newmarket

Call to action!

What are the two books that have most influenced you career (business, technical or philosophical)?  Send the titles to spamcastinfo@gmail.com.  What will we do with this list?  We have two ideas.  First, we will compile a list and publish it on the blog.  Second, we will use the list to drive “Re-read” Saturday. Re-read Saturday is an exciting new feature we will begin in November. More on this new feature next week. So feel free to choose you platform and send an email, leave a message on the blog, Facebook or just tweet the list (use hashtag #SPaMCAST)!

Next

SPaMCAST 313 features our essay on developing an initial backlog.  Developing an initial backlog is an important step to get projects going and moving in the right direction. If a project does not start well, it is hard for it to end well.  We will provide techniques to help you begin well!

Upcoming Events

DCG Webinars:

Agile Risk Management – It Is Still Important! October 24, 2014 11:30 EDT

Has the adoption of Agile techniques magically erased risk from software projects? Or, have we just changed how we recognize and manage risk?  Or, more frighteningly, by changing the project environment through adopting Agile techniques, have we tricked ourselves into thinking that risk has been abolished?

Upcoming Conferences:

I will be presenting at the North East Quality Council 60th Conference October 21st and 22nd in Springfield, MA.

More on all of these great events in the near future! I look forward to seeing all SPaMCAST readers and listeners that attend these great events!

The Software Process and Measurement Cast has a sponsor.

As many you know I do at least one webinar for the IT Metrics and Productivity Institute (ITMPI) every year. The ITMPI provides a great service to the IT profession. ITMPI’s mission is to pull together the expertise and educational efforts of the world’s leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. The ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars. The Software Process and Measurement Cast some support if you sign up here. All the revenue our sponsorship generates goes for bandwidth, hosting and new cool equipment to create more and better content for you. Support the SPaMCAST and learn from the ITMPI.

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.


Categories: Process Management