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

Scaling Agile: Agile Release Trains

3466780657_aec63156b8_b (1)

The Scaled Agile Framework Enterprise (SAFe) is one of the frameworks that has emerged for scaling Agile development. The Agile Release Train (ART) is one of the core concepts introduced as part of the SAFe framework. An ART is a group of logically related effort (train cars) traveling in the same direction (destination) at predictable cadence (speed). At its heart, most everyone on a train is focused on achieving a common goal, which is delivering all types of cargo to a destination. The ART in SAFe is a long-lived team of teams organized around a significant value stream to work towards delivering a common goal. The attributes of an ART interlock to keep it on track to delivering value by ensuring it adheres ot Agile and lean principles.  An ART has the following attributes:

  1. Team of Teams within and ART typically encompass 50 to 125 people. The size limits are a reflection that large groups have issues with communication and cohesion which is problematic when pursuing a common goal and smaller groups have issues absorbing the process overheard which makes development expensive.
  2. ART teams identify and use additional roles not typically found in some Agile frameworks, such as the Release Train Engineer, release managers product management, DevOps and share resources, to name a few.
  3. Teams work with the ART on a long-term basis, 18+ months.
  4. The majority of team members are 100% dedicated to the teams they are involved with.
  5. ARTs are driven by business goals based on the organizations strategic vision and themes, portfolio management constraints and enterprise architectural vision.
  6. ARTs are operationalized and synchronized by cadence at two levels. At a macro level, ARTs leverage a longer cycle cadence called a product increment, which is generally 8 -12 weeks and a shorter Scrum team-level cadence (two weeks is typical).

The Agile Release Train is a tool to help scale Agile to the organizational/product. Conceptually the ART is similar to the operating system (OS) release trains I was first exposed to in the 1990’s. The OS manufacturer and every product manufacturer I have observed from automobile to ATM manufacturer plans the introduction of features over some period of time. An ART provides a mechanism to translate that plan into Agile teams so that organizations can communicate a forecast for the delivery of features to stakeholders and customers. Some degree of predictability is critical if other businesses or parts of a business need to use your input so they can plan their business. Real profits and jobs usually ride on those release trains.

Other frameworks can be used to scale Agile, including DAD, DSDM and arguably Scrum itself. The need for frameworks with additional overheard to scale Agile is controversial. Whether you are an adherent of scaled frameworks or not is less important than having understanding the solutions these frameworks deliver. An Agile Release Train is a tool to organize activity to deliver a common business goal while being both predictable and reacting to the dynamic business environment. At its most basic level isn’t that just a definition of Agile?


Categories: Process Management

SPaMCAST 314 – Crispin, Gregory, More Agile Testing

www.spamcast.net

http://www.spamcast.net

Listen to the interview here!

SPaMCAST 314 features our interview with Janet Gregory and Lisa Crispin.  We discussed their new book More Agile Testing. Testing is core to success in all forms of development.  Agile development and testing are no different. More Agile Testing builds on Gregory and Crispin’s first collaborative effort, the extremely successful Agile Testing to ensure everyone that uses an Agile frameworks delivers the most value possible.

The Bios!

Janet Gregory is an agile testing coach and process consultant with DragonFire Inc. Janet is the is the co-author with Lisa Crispin of Agile Testing: A Practical Guide for Testers and Agile Teams (Addison-Wesley, 2009), and More Agile Testing: Learning Journeys for the Whole Team (Addison-Wesley 2014). She is also a contributor to 97 Things Every Programmer Should Know. Janet specializes in showing Agile teams how testers can add value in areas beyond critiquing the product; for example, guiding development with business-facing tests. Janet works with teams to transition to Agile development, and teaches Agile testing courses and tutorials worldwide. She contributes articles to publications such as Better Software, Software Test & Performance Magazine and Agile Journal, and enjoys sharing her experiences at conferences and user group meetings around the world. For more about Janet’s work and her blog, visit www.janetgregory.ca. You can also follow her on twitter @janetgregoryca.

Lisa Crispin is the co-author, with Janet Gregory, of More Agile Testing: Learning Journeys for the Whole Team (Addison-Wesley 2014), Agile Testing: A Practical Guide for Testers and Agile Teams (Addison-Wesley, 2009), co-author with Tip House of Extreme Testing (Addison-Wesley, 2002), and a contributor to Experiences of Test Automation by Dorothy Graham and Mark Fewster (Addison-Wesley, 2011) and Beautiful Testing (O’Reilly, 2009). Lisa was honored by her peers by being voted the Most Influential Agile Testing Professional Person at Agile Testing Days 2012. Lisa enjoys working as a tester with an awesome Agile team. She shares her experiences via writing, presenting, teaching and participating in agile testing communities around the world. For more about Lisa’s work, visit www.lisacrispin.com, and follow @lisacrispin on Twitter.

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 on the the Software Process and Measurement blog on November 8th with a re-read of Leading Change. 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 315 features our essay on Scrum Masters.  Scrum Masters are the voice of the process at the team level.  Scrum Masters are a critical member of every Agile team. The team’s need for a Scrum Master is not transitory because they evolve together as a team.

Upcoming Events

DCG Webinars:

How to Split User Stories
Date: November 20th, 2014
Time: 12:30pm EST
Register Now

Agile Risk Management – It Is Still Important
Date: December 18th, 2014
Time: 11:30am EST
Register Now

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 314 - Crispin, Gregory, More Agile Testing

Software Process and Measurement Cast - Sun, 11/02/2014 - 23:00

SPaMCAST 314 features our interview with Janet Gregory and Lisa Crispin.  We discussed their new book More Agile Testing. Testing is core to success in all forms of development.  Agile development and testing are no different. More Agile Testing builds on Gregory and Crispin’s first collaborative effort, the extremely successful Agile Testing to ensure everyone that uses an Agile frameworks delivers the most value possible.

The Bios!

Janet Gregory is an agile testing coach and process consultant with DragonFire Inc. Janet is the is the co-author with Lisa Crispin of Agile Testing: A Practical Guide for Testers and Agile Teams (Addison-Wesley, 2009), and More Agile Testing: Learning Journeys for the Whole Team (Addison-Wesley 2014)She is also a contributor to 97 Things Every Programmer Should Know. Janet specializes in showing Agile teams how testers can add value in areas beyond critiquing the product; for example, guiding development with business-facing tests. Janet works with teams to transition to Agile development, and teaches Agile testing courses and tutorials worldwide. She contributes articles to publications such as Better Software, Software Test & Performance Magazine and Agile Journal, and enjoys sharing her experiences at conferences and user group meetings around the world. For more about Janet’s work and her blog, visit www.janetgregory.ca. You can also follow her on twitter @janetgregoryca.

Lisa Crispin is the co-author, with Janet Gregory, of More Agile Testing: Learning Journeys for the Whole Team (Addison-Wesley 2014), Agile Testing: A Practical Guide for Testers and Agile Teams (Addison-Wesley, 2009), co-author with Tip House of Extreme Testing (Addison-Wesley, 2002), and a contributor to Experiences of Test Automation by Dorothy Graham and Mark Fewster (Addison-Wesley, 2011) and Beautiful Testing (O’Reilly, 2009). Lisa was honored by her peers by being voted the Most Influential Agile Testing Professional Person at Agile Testing Days 2012. Lisa enjoys working as a tester with an awesome Agile team. She shares her experiences via writing, presenting, teaching and participating in agile testing communities around the world. For more about Lisa’s work, visit www.lisacrispin.com, and follow @lisacrispin on Twitter.

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 on the the Software Process and Measurement blog on November 8th with a re-read of Leading Change. 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 315 features our essay on Scrum Masters.  Scrum Masters are the voice of the process at the team level.  Scrum Masters are a critical member of every Agile team. The team’s need for a Scrum Master is not transitory because they evolve together as a team.

Upcoming Events

DCG Webinars:

How to Split User Stories
Date: November 20th, 2014
Time: 12:30pm EST
Register Now

Agile Risk Management - It Is Still Important
Date: December 18th, 2014
Time: 11:30am EST
Register Now

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

Announcing Re-read Saturday!

index

There are a number of books that have had a huge impact on my life and career. Many reader of the Software Process and Measure blog and listeners to the podcast have expressed similar sentiments. Re-read Saturday is a new feature that will begin next Saturday. We will begin Re-read Saturday with a re-read of Leading Change. The re-read will extend over a six to eight Saturdays as I share my current interpretation of a book that has a major impact on how I think about the world around me. When the re-read of Leading Change is complete we will dive into the list of books I am compiling from you, the readers and listeners.

Currently the list includes:

  • Seven Habit of Highly Effective People – Stephen Covey (re-read in early 2014)
  • Out of the Crisis – Edward Deming
  • To Be or Not to Be Intimated — Robert Ringer
  • Pulling Your Own Strings — Wayne Dyer
  • The Goal: A Process of Ongoing Improvement – Eliyahu M. Goldratt

So far each book has gotten one “vote” apiece.

How can you get involved in Re-read Saturday? You can begin by answering, “What are the two books that have most influenced you career (business, technical or philosophical)?” Send the titles to spamcastinfo@gmail.com, post the tiles on the blog, Facebook or Twitter with the hashtag #SPaMCAST. We will continue to add to the list and republish it on the blog. When we are close to the end of the re-read of Leading Change we will publish a poll based on the current list (unless there is a clear leader) to select the next book to re-read.

Two of other ways to get involved include adding your perspective to each of the re-read entries by commenting. Second, when the re-read is complete I will invite all of the commenters to participate in a discussion (just like a book club) that will be recorded and published on the Software Process and Measurement Cast.

We begin next Re-read Saturday next week but you can get involved today!

 


Categories: Process Management

Splitting Users Stories: More Anti-patterns

This hood is making an ineffective split of his face.

This hood is making an ineffective split of his face.

An anti-pattern is a typical response to a problem that is usually ineffective. There are numerous patterns for splitting user stories that are generally effective and there are an equal number that are generally ineffective. Splitting User Stories: When Things Go Wrong described some of the common anti-patterns such as waterfall splits, architectural splits, splitting with knowledge and keeping non-value remainders. Here are other equally problematic patterns for splitting user stories that I have observed since writing the original article:

  1. Vendor splits. Vendor splits are splits that are made based on work assignment or reporting structure. Organizations might use personnel from one company to design a solution, another company to code and another to test functionality. Teams and stories are constructed based on organization the team’s members report to rather than a holistic view of the functionality. I recently observed a project that had split stories between on project management and control  and technical activities.  The rational was that since the technical component of the project had been outsourced the work should be put in separate stories so that it would be easy to track work that was the vendors responsibility to complete. Scrumban or Kanban is often a better choice in these scenarios than other lean/Agile techniques.
  2. Generic personas splits. Splitting stories based on a generic persona or into stories where only a generic persona can be identified typically suggests that team members are unsure who really needs the functionality in the user story. Splitting stories without knowing who the story is trying to serve will make it difficult to hold the conversations needed to develop and deliver the value identified in the user story. Conversations are critical in the flesh out requirements and generating feedback in Agile projects.
  3. Too thin splits. While rare, occasionally teams get obsessed by splitting user stories in to thinner and thinner slices. While I have often said that smaller stories are generally better there comes a time when to split further is not worth the time it will take to make the split. Team that get overly obsessed with splitting user stories into thinner and thinner slices generally will spend more time in planning and less in delivering. Each user story should apply INVEST as a criteria to ensure good splits. In addition to using INVEST, each team should adopt a sizing guideline that maximizes the team’s productivity/velocity. Guidelines of this type are reflection of the capacity of the team to a greater extend and the capacity of the organization to a lesser extent.

Splitting stories well can deliver huge benefits to the team and to the organization. Benefits include increased productivity and velocity, improved quality and higher morale. Splitting user stories badly delivers none of the value we would expect from the process and may even cause teams, stakeholders and whole organizations to develop a negative impression of Agile.


Categories: Process Management

iOS localization tricks for Storyboard and NIB files

Xebia Blog - Fri, 10/31/2014 - 23:36

Localization in iOS from Interface Builder designed UI has never been without any problems. The right way of doing localization is by having multiple Strings files. Duplicating Nib or Storyboard files and then changing the language is not an acceptable method. Luckily Xcode 5 has improved this for Storyboards by introducing Base Localization, but I've personally come across several situations where this didn't work at all or when it seemed buggy. Also Nib (Xib) files without ViewController don't support it.

In this post I'll show a couple of tricks that can help with the Localization of Storyboard and Nib files.

Localized subclasses

When you use this method, you create specialized subclasses of view classes that handle the localization in the awakeFromNib() method. This method is called for each view that is loaded from a Storyboard or Nib and all properties that you've set in Interface Builder will be set already.

For UILabels, this means getting the text property, localizing it and setting the text property again.

Using Swift, you can create a single file (e.g. LocalizationView.swift) in your project and put all your subclasses there. Then add the following code for the UILabel subclass:

class LocalizedLabel : UILabel {
    override func awakeFromNib() {
        if let text = text {
            self.text = NSLocalizedString(text, comment: "")
        }
    }
}

Now you can drag a label onto your Storyboard and fill in the text in your base language as you would normally. Then change the Class to LocalizedLabel and it will get the actual label from you Localizable.strings file.

Screen Shot 2014-10-31 at 22.45.46

Screen Shot 2014-10-31 at 22.46.56

No need to make any outlets or write any code to change it!

You can do something similar for UIButtons, even though they don't have a single property for the text on a button.

class LocalizedButton : UIButton {
    override func awakeFromNib() {
        for state in [UIControlState.Normal, UIControlState.Highlighted, UIControlState.Selected, UIControlState.Disabled] {
            if let title = titleForState(state) {
                setTitle(NSLocalizedString(title, comment: ""), forState: state)
            }
        }
    }
}

This will even allow you to set different labels for the different states like Normal and Highlighted.

User Defined Runtime Attributes

Another way is to use the User Defined Runtime Attributes. This method requires slightly more work, but has two small advantages:

  1. You don't need to use subclasses. This is nice when you already use another custom subclass for your labels, buttons and other view classes.
  2. Your keys in the Strings file and texts that show up in the Storyboard don't need to be the same. This works well when you use localization keys such as myCoolTableViewController.header.subtitle. It doesn't look very nice to see those everywhere in your Interface Builder labels and buttons.

So how does this work? Instead of creating a subclass, you instead add a computed property to an existing view class. For UILabels you use the following code:

extension UILabel {

    var localizedText: String {
        set (key) {
            text = NSLocalizedString(key, comment: "")
        }
        get {
            return text!
        }
    }

}

Now you can add a User Defined Runtime Attribute with the key localizedText to your UILabel and have the Localization key as its value.

Screen Shot 2014-10-31 at 23.05.18

Screen Shot 2014-10-31 at 23.06.16

Also here if you want to make this work for buttons, it becomes slightly more complicated. You will have to add a property for each state that needs a label.

extension UIButton {
    var localizedTitleForNormal: String {
        set (key) {
            setTitle(NSLocalizedString(key, comment: ""), forState: .Normal)
        }
        get {
            return titleForState(.Normal)!
        }
    }

    var localizedTitleForHighlighted: String {
        set (key) {
            setTitle(NSLocalizedString(key, comment: ""), forState: .Highlighted)
        }
        get {
            return titleForState(.Highlighted)!
        }
    }
}
Conclusion

Always try and pick the best solution for your problem. Use Storyboard Base Localization if that works well for you. If it doesn't, use the approach with subclasses if you don't need to use another subclass and if you don't care about using your base location strings as localization keys. Else, use the last approach with User Defined Runtime Attributes.

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.

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