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

Function references in Swift and retain cycles

Xebia Blog - Thu, 10/09/2014 - 14:49

The Swift programming language comes with some nice features. One of those features are closures, which are similar to blocks in objective-c. As mentioned in the Apple guides, functions are special types of closures and they too can be passed around to other functions and set as property values. In this post I will go through some sample uses and especially explain the dangers of retain cycles that you can quickly run into when retaining function pointers.

Let's first have a look at a fairly simple objective-c sample before we write something similar in Swift.

Objective-c

We will create a button that executes a block statement when tapped.

In the header file we define a property for the block:

@interface BlockButton : UIButton

@property (nonatomic, strong) void (^action)();

@end

Keep in mind that this is a strong reference and the block and references in the block will be retained.

And then the implementation will execute the block when tapped:

#import "BlockButton.h"

@implementation BlockButton

-(void)setAction:(void (^)())action
{
    _action = action;
    [self addTarget:self action:@selector(performAction) forControlEvents:UIControlEventTouchUpInside];
}

-(void)performAction {
    self.action();
}

@end

We can now use this button in one of our view controllers as following:

self.button.action = ^{
    NSLog(@"Button Tapped");
};

We will now see the message "Button Tapped" logged to the console each time we tap the button. And since we don't reference self within our block, we won't get into trouble with retain cycles.

In many cases however it's likely that you will reference self because you might want to call a function that you also need to call from other places. Let's look as such an example:

-(void)viewDidLoad {
    self.button.action = ^{
        [self buttonTapped];
    };
}

-(void)buttonTapped {
    NSLog(@"Button Tapped");
}

Because our view controller (or it's view) retains our button, and the button retains the block, we're creating a retain cycle here because the block will create a strong reference to self. That means that our view controller will never be deallocated and we'll have a memory leak.

This can easily be solved by using a weak reference to self:

__weak typeof(self) weakSelf = self;
self.button.action = ^{
    [weakSelf buttonTapped];
};

Nothing new so far, so let's continue with creating something similar in Swift.

Swift

In Swift we can create a similar Button that executes a closure instead of a block:

class ClosureButton: UIButton {

    var action: (() -> ())? {
        didSet {
            addTarget(self, action: "callClosure", forControlEvents: .TouchUpInside)
        }
    }

    func callClosure() {
        if let action = action {
            action()
        }
    }
}

It doing the same as the objective-c version (and in fact you could use it from objective-c with the same block as before). We can assign it an action from our view controller as following:

button.action = {
    println("Button Tapped")
}

Since this closure doesn't capture self, we won't be running into problems with retain cycles here.

As mentioned earlier, functions are just a special type of closures. Which is pretty nice, because it lets us reference functions immediately like this:

override func viewDidLoad() {
    button.action = buttonTapped
}

func buttonTapped() {
    println("Button Tapped")
}

Nice and easy syntax and good for functional programming. If only it wouldn't give us problems. Without it being immediately obvious, the above sample does create a retain cycle. Why? We're not referencing self anywhere? Or are we? The problem is that the buttonTapped function is part of our view controller instance. So when the button.action references to that function, it creates a strong reference to the view controller as well. In this case we could fix it by making buttonTapped a class function. But since in most cases you'll want to do something with self in such a function, for example accessing variables, this is not an option.

The only thing we can do to fix this is to make sure that the button won't get a strong reference to the view controller. Just like in our last objective-c sample, we need to create a weak reference to self. Unfortunately there is no easy way to simply get a weak reference to our function. So we need a work around here.

Work around 1: wrapping in closure

We can create a weak reference by wrapping the function in a closure:

button.action = { [weak self] in
    self!.buttonTapped()
}

Here we first create a weak reference of self. And in Swift, weak references are always optional. That means self within this closure is now an optional and need to unwrap it first, which is what the exclamation mark is for. Since we know this code cannot be called when self is deallocated we can safely use the ! instead of ?.

A lot less elegant than immediately referencing our function immediately.

In theory, using an unowned reference to self should also work as following:

button.action = { [unowned self] in
    self.buttonTapped()
}

Unfortunately (for reasons unknown to me) this crashes with a EXC_BAD_ACCESS upon deallocation of the ClosureButton. Probably a bug.

Work around 2: method pointer function

Thanks to a question on StackOverflow about this same problem and an answer provided by Rob Napier, there is a way to make the code a bit more elegant again. We can define a function that does the wrapping in a closure for us:

func methodPointer<T: AnyObject>(obj: T, method: (T) -> () -> Void) -> (() -> Void) {
    return { [weak obj] in
        method(obj!)()
    }
}

Now we can get a weak reference to our function a bit easier.

button.action = methodPointer(self, ViewController.buttonTapped)

The reason this works is because you can get a reference to any instance function by calling it as a class function with the instance (in this case self) as argument. For example, the following all does the same thing:

// normal call
self.buttonTapped()

// get reference through class
let myFunction = MyViewController.buttonTapped(self)
myFunction()

// directly through class
MyViewController.buttonTapped(self)()

However, the downside of this is that it only works with functions that take no arguments and return Void. i.e. methods with a () -> () signature, like our buttonTapped.

For each signature we would have to create a separate function. For example for a function that takes a String parameter and returns an Int:

func methodPointer<T: AnyObject>(obj: T, method: (T) -> (String) -> Int) -> ((String) -> Int) {
    return { [weak obj] string in
        method(obj!)(string)
    }
}

We can then use it the same way:

func someFunction() {
    let myFunction = methodPointer(self, MyViewController.stringToInt)
    let myInt = myFunction("123")
}

func stringToInt(string: String) -> Int {
    return string.toInt()
}
Retain cycles within a single class instance

Retain cycles do not only happen when strong references are made between two instances of a class. It's also possible, and probably less obvious, to create a strong reference within the same instance. Let look an an example:

var print: ((String) -> ())?

override func viewDidLoad() {
    print = printToConsole
}

func printToConsole(message: String) {
    println(message)
}

Here we do pretty much the same as in our button examples. We define an optional closure variable and then assign a function reference to it. This creates a strong reference from the print variable to self and thus creating a retain cycle. We need to solve it by using the same tricks we used earlier.

Another example is when we define a lazy variable. Since lazy variables are assigned after initialisation, they are allowed to reference self directly. That means we can set them to a function reference as following:

lazy var print: ((String) -> ()) = self.printToConsole

Of course this also creates a retain cycle.

Conclusion

To avoid creating retain cycles in Swift you should always remember that a reference to an instance function means that you're referencing the instance as well. And thus when assigning to a variable, you're creating a strong reference. Always make sure to wrap such references in a closure with a weak reference to the instance or make sure to manually set the variables to nil once you're done with them.

Unfortunately Swift does not support weak closure variables, which is something that would solve the problem. Hopefully they will support it in the future or come up with a way to create a weak reference to a function much like we can use [weak self] now in closures.

SAFe and the Release Planning Event

Step out of the chaos!

Step out of the chaos!

Information technology projects are typically a bit chaotic due to interaction of people, the environment and the inherent complexity of software and hardware. The bigger the project, the more complex and chaotic the project becomes. Unfortunately, all products and services can’t be delivered based on the output of a single small team or even a swarm of independent small teams. Coordination and group thinking is required to deliver large projects. Scaled Agile Framework Enterprise (SAFe) addresses this coordination and planning need with a period release planning event. Release planning is one the lightning rods in the discussion of scaled Agile frameworks overall and SAFe in particular.

In SAFe, release planning is done as a large-scale event for each program increment (a period of time typically spanning 8 – 12 weeks). The goal of the of the two-day release planning event is not only to synchronize and energize everyone that is working on the project, but also to assure a coordinated approach to delivering value. A few of the critical success factors for this group planning and coordination activity are:

  1. Release planning is a formal meeting with an agenda and roles. Preparation must occur before participants begin showing up the first day of the meeting. Typically the program’s vision and linkage to the business objectives and the top priorities of the initial program/feature backlog are used as inputs into the event. The release train engineer (who facilitates the event) will need ensure that the workspace and tools the teams will use are prepared.
  2. All members of the program should participate in the release planning event. Release planning is both a planning and coordination event. In the release planning event, teams develop and coordinate their plans for the next set of sprints in an environment that actively encourages communication and sharing. Everyone involved in the program brings different skills and experiences to the table; therefore they can provide unique insights into how the program can deliver maximum value. For example, if a program based in the US was leveraging offshore developers in the Ukraine and testers in India would planning be as effective if team members in India and the Ukraine were excluded and just told the plan? How many challenges and issues would be exposed later in as functionality was delivered that could have been solved by upfront communication?
  3. Release planning events are best when done in person. Programs need to ensure that release planning events are scheduled and that budget is available. Budgets for the events should include travel both travel and logistics.   When travel is not possible, the program leadership should make every effort to make the communication as intimate as possible (in-person being the most intimate and then in descending order: video, audio, test chats and smoke signals). Remember that if it is difficult to hear and participate, participants will get bored and stop paying attention.

A classic advertisement during in 2009 Super Bowl showed a cowboys herding cats. Large projects might not be quite as chaotic as that, however if teams don’t have a clear vision or don’t understand the interactions and relationships between what they are delivering and what others are delivering chaos could ensue. The Agile release planning event in SAFe is a mechanism for solving the planning and communication conundrum.


Categories: Process Management

The Case Against Scaled Frameworks

Are scaled frameworks process-focused, not people-focused.

Are scaled frameworks process-focused, not people-focused.

As noted in the Heavy Weight Championship of Agile, there has been a substantial amount of animated “discussion” about whether there is a need for scaled frameworks.  The three major players in the scaled framework arena, DSDM, DAD and SAFe all combine component Agile, lean, product flow and other techniques to address perceived needs in the overall software development community.  The primary issues are:

  1. Scaled frameworks are not “Agile.” This argument stems from the inclusion of techniques such as large scale release planning and hardening sprints (SAFe), an inception phase (DAD) and classic project management documentation (DSDM) to name a few techniques that draw attention. The argument is correct. These techniques are, strictly speaking, not Agile, however neither are the lean and product flow techniques that have become de rigor in many “Agile” implementations.  Our definition of what is Agile has evolved over time. The twelve principles in the Agile Manifesto provide a core set of values to use as a tool to evaluate whether any addition to our practice is Agile or not.
  2. The scaled frameworks are process-focused rather than people-focused.  One of the greatest successes of the Agile movement has been to refocus the software development process (including development, enhancement and maintenance) on people and communication without losing sight of the fact that software development is a process. This is generally interpreted that teams self-manage and self-organize to meet the demands for the work they are asked to perform.  All three of the major scaled frameworks embrace Scrum as their central team management tool.  What tends to be more explicitly delineated in the scaled frameworks is the role of the larger organization (management) to decide and plan for what will be done in terms of release planning.  I agree with the argument that large organizations are trading nimbleness for additional predictability (with the attendant risk). Processes and the predictability/coordination needs they address are driven because large organizations have so many more moving parts (for example marketing, sales, production, customer service, legal departments and that generally does not scratch the surface) that more free flowing communication is less effective.  This is one of the reasons why large organizations tend to be less nimble, but can tackle huge programs. 

The criticisms are valid, however overly specific to one type or culture of work.  In broader world ranging from small cutting edge firms to large, regulation-bound behemoths, there will be mechanisms needed to effectively deliver value.  We need to interpret those mechanisms through the eyes of the principles in Agile, lean and other methods to ensure we do not have runaway bloat.  What does not go away in any implementation scaled or not scaled is core premise of Agile that the people doing the work are the people who best figure how to approach and organize to get they need to accomplish done.  Teams are best positioned to react to the facts on the ground however they need to do so within the boundaries of business need and organizational culture.


Categories: Process Management

What Is Quality?

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

Agile teams build high-quality products. Agile team members write high-quality code. Agile teams produce functionality quickly by not sacrificing quality.

Each of these is something I’ve said before. And if you haven’t said these exact things, you’ve likely said something similar.

Quality gets mentioned a lot in discussions about agile. And so, perhaps it’s worth clarifying my definition of quality. Of course, others have thought about quality more deeply than I’m capable of. And so, I won’t be providing a new definition of quality here. But I will explain how I think of quality.

One of the leading advocates for quality was Philip Crosby. In the 1970s he proclaimed that “quality is free” because doing something right the first time at a high level of quality was cheaper than fixing it later. Crosby defined quality as “conformance to requirements.”

I never really bought into Crosby “conformance with requirements” approach (even before agile came around) because there was never a way to be confident requirements were accurate. Saying something like old Microsoft Bob was high quality because it complied with some ill-conceived requirements document never felt right to me.

Similarly, quality isn’t just being bug-free though, as that’s the same problem.

Another approach to defining quality comes from Joseph Juran. He was one of a number of management theorists who worked in Japan in the 1950s. Juran defined quality as “fitness for use”:

"An essential requirement of these products is that they meet the needs of those members of society who will actually use them. This concept of fitness for use is universal. It applies to all goods and services, without exception. The popular term for fitness for use is Quality, and our basic definition becomes: quality means fitness for use."

This definition of quality really resonates with me. Quality is “fitness for use.” A high-quality product does what its customers want in such a way that they actually use the product. Something that conforms to ill-conceived requirements (such as Microsoft Bob) is not high quality. Something that is buggy isn’t high quality because it isn’t fit for use.

What do you think? Is quality best thought of as “conformance to requirements?” Or “fitness for use?” Or perhaps something else entirely? Please share your thoughts in the comments below.

What Is Quality?

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

Agile teams build high-quality products. Agile team members write high-quality code. Agile teams produce functionality quickly by not sacrificing quality.

Each of these is something I’ve said before. And if you haven’t said these exact things, you’ve likely said something similar.

Quality gets mentioned a lot in discussions about agile. And so, perhaps it’s worth clarifying my definition of quality. Of course, others have thought about quality more deeply than I’m capable of. And so, I won’t be providing a new definition of quality here. But I will explain how I think of quality.

One of the leading advocates for quality was Philip Crosby. In the 1970s he proclaimed that “quality is free” because doing something right the first time at a high level of quality was cheaper than fixing it later. Crosby defined quality as “conformance to requirements.”

I never really bought into Crosby “conformance with requirements” approach (even before agile came around) because there was never a way to be confident requirements were accurate. Saying something like old Microsoft Bob was high quality because it complied with some ill-conceived requirements document never felt right to me.

Similarly, quality isn’t just being bug-free though, as that’s the same problem.

Another approach to defining quality comes from Joseph Juran. He was one of a number of management theorists who worked in Japan in the 1950s. Juran defined quality as “fitness for use”:

"An essential requirement of these products is that they meet the needs of those members of society who will actually use them. This concept of fitness for use is universal. It applies to all goods and services, without exception. The popular term for fitness for use is Quality, and our basic definition becomes: quality means fitness for use."

This definition of quality really resonates with me. Quality is “fitness for use.” A high-quality product does what its customers want in such a way that they actually use the product. Something that conforms to ill-conceived requirements (such as Microsoft Bob) is not high quality. Something that is buggy isn’t high quality because it isn’t fit for use.

What do you think? Is quality best thought of as “conformance to requirements?” Or “fitness for use?” Or perhaps something else entirely? Please share your thoughts in the comments below.

The Heavyweight Championship of Agile

Without a framework, the building falls.

Without a framework, the building falls.

Team-based frameworks, techniques and methods have dominated the discussion over short history of Agile as a named movement. Concepts like Scrum and Extreme Programing (just two of the more prominent frameworks) caught the interest of software developers and IT management for many reasons, including the promise of customer responsiveness, faster delivery rates, increased productivity and the implementation excesses of heavyweight frameworks, such as the CMMI. Excess of the later still resounds in the minds of many developers, process improvement specialist and IT leaders. The fear of excess overhead and administration has dampened the discussion and exploration of techniques to scale Agile to the address program level and enterprise issues.  In the past few years, three primary frameworks have emerged to vie for the heavyweight championship of Agile. They are:

  1. Dynamic Systems Development Method (DSDM). DSDM is a project delivery/system development method. Originally released in 1994, DSDM predates the Agile Manifesto and was one the frameworks that drove the evolution of lightweight incremental development. DSMD takes a broader view of projects and integrates other lifecycle steps into the framework on top of a developer lead Scrum team. The framework has been tailored to integrate the PRINCE2 (European Project Management Standard) as a project and program management tool. DSDM is open source. (http://www.dsdm.org/)
  2. Disciplined Agile Delivery (DAD). DAD is a framework that incorporates concepts from many of the standard techniques and frameworks (Scrum, lean, Agile modeling and Agile Unified Process to name a few) to develop an organizational model. Given that DAD was developed and introduced after the introduction of Agile-as-a-movement, DAD explicitly reflects the Agile principles espoused in the Agile Manifesto while reflecting organizational scaling concerns. DAD has been influenced and championed by Scott Amber (Disciplined Agile Delivery: A Practitioner’s Guide to Agile, 2012) and IBM. The model is proprietary (http://disciplinedagiledelivery.com/)
  3. Scaled Agile Framework Enterprise (SAFe). SAFe as a framework leverages Kanban as tool to introduce organizational portfolio management and then to evolve concepts to programs to project and finally to Scrum teams. SAFe explicitly addresses the necessity of architecture to develop in lockstep with functionality. As with DSDM and DAD, SAFe’s goal is provide a framework to scale Agile in a manner that addresses the concerns and needs to the overall business, IT and development organizations. SAFe is a proprietary framework that was originally developed by Dean Leffingwell and now is supported by the company Scaled Agile. (http://scaledagileframework.com/)

There is a huge amount of controversy in the Agile community about the need for frameworks for scaling Agile, as evidenced by shouting matches at conferences and the vitriol on message boards. However many large organizations in both commercial and governmental organizations are using DSDM, DAD and SAFe as mechanisms to scale Agile.  Shouting is not going to stop what many organizations view as a valuable mechanism to deliver functionality to their customers.


Categories: Process Management

Why 'Why' Is Everything

Xebia Blog - Mon, 10/06/2014 - 20:46

The 'Why' part is perhaps the most important aspect of a user story. This links to the sprint goal which links ultimately to the product vision and organisation's vision.

Lately, I got reminded of the very truth of this statement. My youngest son is part of a soccer team and they have training every week. Part of the training are exercises that use a so-called speedladder.

foto-1

After the training while driving home I asked him what he especially liked about the training and what he wants to do differently next time. This time he answered that he didn't like the training at all. So I asked him what part he disliked: "The speedladder. It is such a stupid thing to do.". Although I realised it to be a poor mans answer I told him that some parts are not that nice and he needs to accept that: practising is not always fun. I wasn't happy with the answer but couldn't think of a better one.

Some time passed when I overheard the trainers explaining to each other that the speedladder is for improving the 'footwork', coordination, and sensory development. Then I got an idea!
I knew that his ambition is to become as good as Messi :-) so when at home I explained this to my son and that it helps him to improve feints and unparalleled actions. I noticed his twinkling eyes and he enthusiastically replied: "Dad, can we buy a speedladder so I can practise at home?".  Of course I did buy one! Since then the 'speedladder' is the most favourable part of the soccer training!

Summary

The goal, purpose and the 'Why' is the most important thing for persons and teams. Communicating this clearly to the team is one of the most important things a product owner and organisation need to do in order to get high performant teams.

How to create a Value Stream Map

Xebia Blog - Mon, 10/06/2014 - 08:05

Value Stream Mapping (VSM) is a -very- useful tool to gain insight in the workflow of a process and can be used to identify both Value Adding Activities and Non Value Adding Activities in a process stream while providing handles for optimizing the process chain. The results of a VSM can be used for many occasions: from writing out a business case, to defining a prioritized list to optimize processes within your organization, to pinpointing bottlenecks in your existing processes and gain a common understanding of process related issues.

When creating a VSM of your current software delivery process you quite possibly will be amazed by the amount of waste and therefor the room for improvement you might find. I challenge you to try this out within your own organization. It will leave you with a very powerful tool to explain to your management the steps that need to change, as it will leave you with facts.

To quickly get you started, I wrote out some handles on how to write out a proper Value Stream Map.

In many organizations there is the tendency to ‘solely’ perform local optimizations to steps in the process (i.e. per Business Unit), while in reality the largest process optimizations can be gained by optimizing the area’s which are in between the process steps and do not add any value to the customer at all; the Non Value Adding activities. Value Stream Mapping is a great tool for optimizing the complete process chain, not just the local steps.

Local_vs_complete

The Example - Mapping a Software Delivery Process
Many example value streams found on the internet focus on selling a mortgage, packaging objects in a factory or some logistic process. The example I will be using focuses on a typical Software Delivery Processes as we still see them today: the 'traditional' Software Delivery Process containing many manual steps.

You first need to map the 'as-is' process as you need this to form the baseline. This baseline provides you the required insight to remove steps from the process that do not add any value to your customer and therefor can be seen as pure waste to your organization.

It is important to write out the Value Stream as a group process (a workshop), where group-members represent people that are part of the value chain as it is today*. This is the only way to spot (hidden) activities and will provide a common understanding of the situation today. Apart from that, failure to execute the Value Stream Mapping activity as a group process will very likely reduce the acceptance rate at the end of the day. Never write out a VSM in isolation.

Value Stream mapping is 'a paper and pencil tool’ where you should ask participants to write out the stickies and help you form the map. You yourself will not write on stickies (okay, okay, maybe sometimes … but be careful not to do the work for the group). Writing out a process should take you about 4 to 6 hours, including discussions and the coffee breaks of course. So, now for the steps!

* Note that the example value stream is a simplified and fictional process based on the experience at several customers.

Step 0 Prepare
Make sure you have all materials available.

Here is a list:
- two 4 meter strokes of brown paper.
- Plastic tape to attach paper to the wall
- stickies square multiple colors
- stickies rectangle multiple colors
- small stickies one or two colors
- lot’s of sharpies (people need to be able to pick up the pens)
- colored ‘dot' stickies.

What do you need? (the helpful colleague not depicted)

What do you need? (the helpful colleague not depicted)

Step 1 & 2 define objectives and process steps
Make sure to work one process at a time and start off with defining customer objectives (the Voice Of Customer). A common understanding of the VoC is important because in later stage you will determine with the team which activities are really adding to this VoC and which steps are not. Quite often these objectives are defined in Time, Cost and Quality. For our example, let’s say the customer would like to be able to deliver a new feature every hour, with a max cost of $1000 a feature and with zero defects.

First, write down the Voice of the Customer in the top right corner. Now, together with the group, determine all the actors (organizations / persons / teams) that are part of the current process and glue these actors as orange stickies to the brown paper.

Defining Voice of Customer and Process Steps

Defining Voice of Customer and Process Steps

Step 3 Define activities performed within each process step
With the group, per determine the activities that take place. Underneath the orange stickies, add green stickies that describe the activities that take place in a given step.

Defining activities performed in each step

Defining activities performed in each step

Step 4 Define Work in Progress (WiP)
Now, add pink stickies in between the steps, describing the number of features / requirements / objects / activities that is currently in process in between actors. This is referred to as WiP - Work in Progress. Whenever there is a high WiP limit in between steps, you have identified a bottleneck causing the process 'flow' to stop.

On top of the pink WiP stickies containing particular high WiP levels, add a small sticky indicating what the group thinks is causing the high WiP. For instance, a document has to be distributed via internal mail, or a wait is introduced for a bi-weekly meeting or travel to another location is required. This information can later be used to optimize the process.

Note that in the workshop you should also take some time to finding WiP within the activities itself (this is not depicted in this example). Spend time on finding information for causes of high WiP and add this as stickies to each activity.

Define work in process

Define work in process

Step 5 Identify rework
Rework is waste. Still, many times you'll see that a deliverable is to be returned to a previous step for reprocessing. Together with the group, determine where this happens and what is the cause of this rework. A nice additional is to also write out first-time-right levels.

Identify rework

Identify rework

Step 6 Add additional information
Spend some time in adding additional comments for activities on the green stickies. Some activities might for instance not be optimized, are not easy to handle or from a group perspective considered obsolete. Mark these comments with blue stickies next to the activity at hand.

Add additional information

Add additional information

Step 7 Add Process time, Wait time and Lead time and determining Process Cycle Efficiency

Now, as we have the process more or less complete, we can start adding information related to timing. In this step you would like to determine the following information:

  • process time: the real amount of time that is required to perform a task without interruptions
  • lead time: the actual time that it takes for the activity to be completed (also known as elapse time)
  • wait time: time when no processing is done at all, for example when for waiting on a 'event' like a bi-weekly meeting.

(Not in picture): for every activity on the green sticky, write down a small sticky with two numbers vertically aligned. The top-number reflects the process-time, (i.e. 40 hours). The bottom-number reflects the lead time (i.e. 120 hours).

(In picture): add a block diagram underneath the process, where timing information in the upper section represents total processing time for all activities and timing information the lower section represents total lead time for all activities. (just add up the timing information for the individual activities I described in previous paragraph). Also add noticeable wait time in-between process steps. As a final step, to the right of this block diagram, add the totals.

Now that you have all information on the paper, the following  can be calculated:

  • Total Process Time - The total time required to actually work on activities if one could focus on the activity at hand.
  • Total Lead Time - The total time this process actually needs.
  • Project Cycle Efficiency (PCE): -> Total Process Time / Total Lead Time *100%.

Add this information to the lower right corner of your brown paper. The numbers for this example are:

Total Process Time: add all numbers in top section of stickies: 424 hours
Process Lead Time (PLT): add all numbers in lower section of stickies + wait time in between steps: 1740 hours
Project Cycle Efficiency (PCE) now is: -> Total Process  Time / Total Process Lead Time: 24%.
Note that 24% is -very- high which is caused by using an example. Usually you’ll see a PCE at about 4 - 8% for a traditional process.

Add process, wait and lead times

Add process, wait and lead times

Step 8 Identify Customer Value Add and Non Value Add activities
Now, categorize tasks into 2 types: tasks that add value to the customer (Customer Value Add, CVA) and tasks that do not add value to the customer (Non Value Add, NVA). The NVA you can again split into two categories: tasks that add Business Value (Business Value Add, BVA) and ‘Waste’. When optimizing a process, waste is to be eliminated completely as it does not add value to the customer nor the business as a whole. But also for the activities categorized as 'BVA', you have to ask yourself whether these activities add to the chain.

Mark CVA tasks with a green dot, BVA tasks with a blue dot and Waste with a red dot. Put the legend on the map for later reference.

When identifying CVA, NVA and BVA … force yourself to refer back to the Voice of Customer you jotted down in step 1 and think about who is your customer here. In this example, the customer is not the end user using the system, but the business. And it was the business that wanted Faster, Cheaper & Better. Now when you start to tag each individual task, give yourself some time in figuring out which tasks actually add to these goals.

Determine Customer Value Add & Non Value Add

Determine Customer Value Add & Non Value Add

To give you some guidance on how you can approach tagging each task, I’ll elaborate a bit on how I tagged the activities. Note again, this is just an example, within the workshop your team might tag differently.

Items I tagged as CVA: coding, testing (unit, static, acceptance), execution of tests and configuration of monitoring are adding value to the customer (business). Why? Because all these items relate to a faster, better (high quality through test + monitoring) and cheaper (less errors through higher quality of code) delivery of code.

Items I tagged as BVA: documentation, configuration of environments, deployments of VMs, installation of MW are required to be able to deliver to the customer when using this (typical waterfall) Software Delivery Processes. (Note: I do not necessarily concur with this process.) :)

Items I tagged as pure Waste, not adding any value to the customer: items like getting approval, the process to get funding (although probably required), discussing details and documenting results for later reference or waiting for the Quarterly release cycle. Non of these items are required to either deliver faster, cheaper or better so in that respect these items can be considered waste.

That's it (and step 9) - you've mapped your current process
So, that’s about it! The Value Stream Map is now more or less complete an contains all relevant information required to optimize the process in a next step. Step 9 here would be: Take some time to write out items/bottlenecks that are most important or easy to address and discuss internally with your team about a solution. Focus on items that you either tagged as BVA or pure waste and think of alternatives to eliminate these steps. Put your customer central, not your process! Just dropping an activity as a whole seems somewhat radical, but sometimes good ideas just are! Note by the way that when addressing a bottleneck, another bottleneck will pop up. There always will be a bottleneck somewhere in the process and therefor process optimization must be seen as a continuous process.

A final tip: to be able to perform a Value Stream Mapping workshop at the customer, it might be a good idea to join a more experienced colleague first, just to get a grasp of what the dynamics in such a workshop are like. The fact that all participants are at the same table, outlining the delivery process together and talk about it, will allow you to come up with an optimized process on which each person will buy in. But still, it takes some effort to get the workshop going. Take your time, do not rush it.

For now, I hope you can use the steps above the identify the current largest bottlenecks within your own organization and get going. In a next blog, if there is sufficient interest, I will write about what would be possible solutions in solving the bottlenecks in my example. If you have any ideas, just drop a line below so we can discuss! The aim for me would be to work towards a solution that caters for Continuous Delivery of Software.

Michiel Sens.

SPaMCAST 310 – Mike Burrows, Kanban from the Inside

www.spamcast.net

http://www.spamcast.net

Listen to the SPaMCAST 310

Software Process and Measurement Cast 310 features our interview with Mike Burrows. This is Mike’s second visit to the Software Process and Measurement Cast.  In this visit we discussed his new book, Kanban from the Inside (Kindle).  The book lays out why Kanban is a management method built on a set of values rather than just a set of techniques. Mike explains why Kanban leads to better outcomes for projects, managers, organizations and customers!

Mike is the UK Director and Principal Consultant at David J Anderson and Associates. In a career spanning the aerospace, banking, energy and government sectors, Mike has been a global development manager, IT director and software developer. He speaks regularly at Lean/Kanban-related events in several countries and his book Kanban from the Inside (Kindle)was published in September.

Mike’s email is mike@djaa.com
Twitter: https://twitter.com/asplake and @KanbanInside
Blog is http://positiveincline.com/index.php/about/UK

Kanban conference: http://lkuk.leankanban.com/
Kanban conference series: http://conf.leankanban.com/

Next

SPaMCAST 311 features our essay on backlog grooming. Backlog grooming is an important technique that can be used in any Agile or Lean methodology. At one point the need for backlog grooming was debated, however most practitioners now find the practice useful. The simplest definition of backlog grooming is the preparation of the user stories or requirements to ensure they are ready to be worked on. The act of grooming and preparation can cover a wide range of specific activities and can be performed at any time). In the next podcast we get into the nuts and bolts of making your backlog better!

Upcoming Events

DCG Webinars:

Agile Risk Management – It Is Still Important! October 24, 2014 11:230 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

SPaMCAST 310 – Mike Burrows, Kanban from the Inside

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

Software Process and Measurement Cast 310 features our interview with Mike Burrows. This is Mike’s second visit to the Software Process and Measurement Cast.  In this visit we discussed his new book, Kanban from the Inside (Kindle).  The book lays out why Kanban is a management method built on a set of values rather than just a set of techniques. Mike explains why Kanban leads to better outcomes for projects, managers, organizations and customers!

Mike is the UK Director and Principal Consultant at David J Anderson and Associates. In a career spanning the aerospace, banking, energy and government sectors, Mike has been a global development manager, IT director and software developer. He speaks regularly at Lean/Kanban-related events in several countries and his book Kanban from the Inside (Kindle)was published in September.

Mike’s email is mike@djaa.com
Twitter: https://twitter.com/asplake and @KanbanInside
Blog is http://positiveincline.com/index.php/about/UK

Kanban conference: http://lkuk.leankanban.com/
Kanban conference series: http://conf.leankanban.com/

Next

SPaMCAST 311 features our essay on backlog grooming. Backlog grooming is an important technique that can be used in any Agile or Lean methodology. At one point the need for backlog grooming was debated, however most practitioners now find the practice useful. The simplest definition of backlog grooming is the preparation of the user stories or requirements to ensure they are ready to be worked on. The act of grooming and preparation can cover a wide range of specific activities and can be performed at any time). In the next podcast we get into the nuts and bolts of making your backlog better!

Upcoming Events

DCG Webinars:

Agile Risk Management – It Is Still Important! October 24, 2014 11:230 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

Distributed Agile: Checklist of the Basics

Hydrogen is elementary!

Hydrogen is elementary!

Hand drawn chart Saturday.

In Scrum there are four-ish basic meetings. They are sprint planning, daily stand-up, demonstrations, retrospectives and backlog grooming (the “ish” part). Whether distributed or co-located, these meetings are critical to planning, communication and controlling how Agile is typically practiced. Getting them right is not optional, especially when the Agile team is distributed. While there specific techniques for each type of meeting (some people call them rituals) there a few basics that can be used as a checklist. They are:

  • Schedule and invite participants. Team members are easy! Schedule all standard meetings for team members upfront for as many sprints as you are panning to have. As a team, decide on who will participate in the demo and make sure they are invited as early as possible.
  • Review the goals and rules of the meeting upfront. Don’t assume that everyone knows the goal of the meeting and the ground rules for their participation.
  • Publish an agenda. Agendas provide focus for any meeting. While an agenda for a daily stand-up might sound like overkill (and for long-term, stable teams it probably is), I either review the outline of the meeting or send the outline to all participants before the meeting starts.
  • Check the tools and connections. Distributed teams will require tools and software packages; including audio conferencing, video conferencing, screen sharing and chat software. Ensure they are on, connected and that everyone has access BEFORE the meeting starts.
  • Ensure active facilitation is available. All meetings are facilitated. Actively facilitated meetings are typically more focused, while un-facilitated meetings tend to be less focused and more ad-hoc. Active or passive facilitation is your choice. Distributed teams should almost choose facilitation. If using Scrum, part of role of the Scrum master is to act as a facilitator. The Scrum master guides the team and participants to ensure all of the meetings are effective and meet their goals.
  • Hold a meeting retrospective. Spend a few moments after each meeting to validate the goals were met and what could be done better in the future.

Agile is not magic. All Agile teams use techniques that assume the team has a common goal to guide them and then use feedback generated through communication to stay on track. Distributed Agile teams need to pay more careful attention to the basics. The Scrum master should strive to make the tools and process needed for all of the meetings fade into the background; for the majority of the team the end must be more important than the process.


Categories: Process Management

Distributed Agile: Retrospectives

Retrospectives are reflective!

Retrospectives are reflective!

 

Retrospectives are the team’s chance to make their life better. Process of making the team’s life better may mean confronting hard truths and changing how work is done. Hard conversations require trust and safety. Trust and safety are attributes that are hard to generate remote, especially if team members have never met each other. Facilitation and techniques tailored to distributed teams are needed to get real value from retrospectives when the team is distributed.

  1. Bring team members together. Joint retrospectives will serve a number of purposes including building relationships and trust. The combination of deeper relationships and trust will help team members tackle harder conversations when team members are apart.
  2. Use collaboration tools. Many retrospective techniques generate lists and then ask participants to vote. Listing techniques work best when participants see what is being listed rather than trying to remember or reference any notes that have been taken. I have used free mind-mapping tools (such as FreeMind) and screen-sharing software to make sure everyone can see the “list.”
  3. Geographic distances can mask culture differences. The facilitator needs to make sure he or she is aware of cultural differences (some cultures find it harder to expose and discuss problems). Differences in culture should be shared with the team before the retrospective begins. Consider adding a few minutes before beginning retrospective to discuss cultural issues if your team has members in or from different counties or if there are glaring cultural differences. Note the same ideas can be used to address personality differences.
  4. Use more than one facilitator. Until team members get comfortable with each other consider having a second (or third) facilitator to support the retrospective. When using multiple facilitators ensure that the facilitators understand their roles and are synchronized on the agenda.
  5. Consider assigning pre-retrospective homework. Poll team members for comments and issues before the retrospective session. The issues and comments can be shared to seed discussions, provide focus or just break the ice.

All of these suggestions presume that the retrospective has stable tele/video communication tools and the meeting time has been negotiated. If participation due to attendance, first ask what the problem is and if the problem is that attending a retrospective in the middle of the night is hard then consider an alternate meeting time (share the time zone pain).

Retrospectives are critical to help teams grow and become more effective. Retrospectives in distributed teams are harder than in co-located teams. The answer to being harder should be to use these techniques or others to facilitate communication and interaction. The answer should never be to abandon retrospectives, leave remote members out of the meeting or to hold separate but equal retrospectives. Remember, one team and one retrospective but that only work well when members trust each other and feel safe to share their ideas for improvement.


Categories: Process Management

Integrating Geb with FitNesse using the Groovy ConfigSlurper

Xebia Blog - Fri, 10/03/2014 - 18:01

We've been playing around with Geb for a while now and writing tests using WebDriver and Groovy has been a delight! Geb integrates well with JUnit, TestNG, Spock, and Cucumber. All there is left to do is integrating it with FitNesse ... or not :-).

Setup Gradle and Dependencies

First we start with grabbing the gradle fitnesse classpath builder from Arjan Molenaar.
Add the following dependencies to the gradle build file:

compile 'org.codehaus.groovy:groovy-all:2.3.7'
compile 'org.gebish:geb-core:0.9.3'
compile 'org.seleniumhq.selenium:selenium-java:2.43.1
Configure different drivers with the ConfigSlurper

Geb provides a configuration mechanism using the Groovy ConfigSlurper. It's perfect for environment sensitive configuration. Geb uses the geb.env system property to determine the environment to use. So we use the ConfigSlurper to configure different drivers.

import org.openqa.selenium.chrome.ChromeDriver
import org.openqa.selenium.firefox.FirefoxDriver

driver = { new FirefoxDriver() }

environments {
  chrome {
    driver = { new ChromeDriver() }
  }
}
FitNesse using the ConfigSlurper

We need to tweak the gradle build script to let FitNesse play nice with the ConfigSlurper. So we pass the geb.env system property as a JVM argument. Look for the gradle task "wiki" in the gradle build script and add the following lines.

def gebEnv = (System.getProperty("geb.env")) ? (System.getProperty("geb.env")) : "firefox"
jvmArgs "-Dgeb.env=${gebEnv}"

Since FitNesse spins up a separate 'service' process when you execute a test, we need to pass the geb.env system property into the COMMAND_PATTERN of FitNesse. That service needs the geb.env system property to let Geb know which environment to use. Put the following lines in the FitNesse page.

!define COMMAND_PATTERN {java -Dgeb.env=${geb.env} -cp %p %m}

Now you can control the Geb environment by specifying it on the following command line.

gradle wiki -Dgeb.env=chrome

The gradle build script will pass the geb.env system property as JVM argument when FitNesse starts up. And the COMMAND_PATTERN will pass it to the test runner service.

Want to see it in action? Sources can be found here.

Distributed Agile: Demonstrations

Demonstrations!

Demonstrations!

Demonstrations are an important tool for teams to gather feedback to shape the value they deliver.  Demonstrations provide a platform for the team to show the stories that have been completed so the stakeholders can interact with the solution.  The feedback a team receives not only ensures that the solution delivered meets the needs but also generates new insights and lets the team know they are on track.  Demonstrations should provide value to everyone involved. Given the breadth of participation in a demo the chance of a distributed meeting is even more likely.  Techniques that support distributed demonstrations include:

  1. More written documentation: Teams, especially long-established teams, often develop shorthand expressions that convey meaning fall short before a broader audience. Written communication can be more effective at conveying meaning where body language can’t be read and eye contact can’t be made. Publish an agenda to guide the meeting; this will help everyone stay on track or get back on track when the phone line drops. Capture comments and ideas on paper where everyone can see them.  If using flip charts, use webcams to share the written notes.  Some collaboration tools provide a notepad feature that stays resident on the screen that can be used to capture notes that can be referenced by all sites.
  2. Prepare and practice the demo. The risk that something will go wrong with the logistics of the meeting increase exponentially with the number of sites involved.  Have a plan for the demo and then practice the plan to reduce the risk that you have not forgotten something.  Practice will not eliminate all risk of an unforeseen problem, but it will help.
  3. Replicate the demo in multiple locations. In scenarios with multiple locations with large or important stakeholder populations, consider running separate demonstrations.  Separate demonstrations will lose some of the interaction between sites and add some overhead but will reduce the logistical complications.
  4. Record the demo. Some sites may not be able to participate in the demo live due to their time zones or other limitations. Recording the demo lets stakeholders that could not participate in the live demo hear and see what happened and provide feedback, albeit asynchronously.  Recording the demo will also give the team the ability to use the recording as documentation and reference material, which I strongly recommend.
  5. Check the network(s)! Bandwidth is generally not your friend. Make sure the network at each location can support the tools you are going to use (video, audio or other collaboration tools) and then have a fallback plan. Fallback plans should be as low tech as practical.  One team I observed actually had to fall back to scribes in two locations who kept notes on flip charts by mirroring each-other (cell phones, bluetooth headphones and whispering were employed) when the audio service they were using went down.

Demonstrations typically involve stakeholders, management and others.  The team needs feedback, but also needs to ensure a successful demo to maintain credibility within the organization.  In order to get the most effective feedback in a demo everyone needs to be able to hear, see and get involved.  Distributed demos need to focus on facilitating interaction more than in-person demos. Otherwise, distributed demos risk not being effective.


Categories: Process Management

Distributed Agile: Backlog Grooming Meetings

Understanding how a story or a group of stories fits into the big picture is sometime like reading a single line of Shakespeare and trying to develop the plot for the entire play.

Understanding how a story or a group of stories fits into the big picture is sometime like reading a single line of Shakespeare and trying to develop the plot for the entire play.

There are two reasons to hold backlog grooming meetings. The first is to make sprint planning more efficient and effective. The second reason is make sure you understand your backlog. When teams don’t spend the time needed to groom the backlog, planning meetings can be very tense and extend for hours . . . and hours. Backlog grooming sessions can be whole team activities (rare) or sub-team activities (more common). The most common technique used to generate a sub-team for grooming is the Three Amigos (or some variant). The tallest hurdle all distributed teams face is ensuring effective communications, followed quickly by staying focused on the task at hand. Many of the same techniques we discussed for sprint planning in distributed teams will be effective, however backlog grooming has a few unique twists.

  1. Everybody needs to see the story at all times. Everyone involved must be able to see the story being groomed, preferably as it is being edited. Reading a story to someone at the other end of a phone and then amending the reading as you wordsmith the statement is difficult for many people to conceptualize. Most webinar tools now have whiteboard options. Cut and paste the story and acceptance criteria into the whiteboard feature so that everyone can see the words. One team I recently worked with used messaging software to approximate the process (it worked fairly well). Tools like webcams and telepresence can be used, however make sure the story and the acceptance criteria are easily readable by all parties. When a team member can’t hear or see well enough to stay involved, they will lose focus and probably start doing email.
  2. The right people and locations need to be involved. There are many shades of distributed teams, ranging from two locations to completely dispersed (everyone in different locations). The goal of grooming is to make sure the backlog items that may be used in the next sprint are understood, well-formed and have acceptance criteria. Typically, grooming is most effective when the three major team constituencies are to be involved: the business, the developers and the testers. When a team is distributed, locations can become constituencies that need to be involved to ensure that the grooming session attains the goal of making sure the stories are understood. This is an argument for whole team grooming sessions so that no location feels left out.
  3. Use story maps to link stories the big picture. Understanding how a story or a group of stories fits into the big picture is sometime like reading a single line of Shakespeare and trying to develop the plot for the entire play. When a team is distributed, it becomes more difficult for members to have a side conversation to get things back on track or to develop ways to stay aligned to project’s big picture without a more formal reference. A story map provides a frame of reference so that the team members involved in the grooming session can see how the stories fit into overall project. The use of a story map in the grooming process makes it easier to identify or develop a theme for the next sprint (a theme provides focus and direction to the team).

Backlog grooming is a process to make sure the stories that might be used in the next sprint are understood, well-formed and have acceptance criteria. When backlogs are not well groomed teams tend to spend a lot time planning and re-planning rather than delivering value. This is true whether a team is distributed or not. The problem is that when a team is distributed any hiccup takes more effort to fix, making grooming even more important.


Categories: Process Management

Distributed Agile: Daily Stand-up Meetings

Stand-ups are best on your feet!

Stand-ups are best on your feet!

Distributed Agile teams require a different level of care and feeding than a co-located team in order to ensure that they are as effective as possible. This is even truer for a team that is working through their forming-storming-norming process. Core to making Agile-as-framework work effectively is the concepts of team and communication. Daily stand-up meetings are one the most important communication tools used in Scrum or other Agile/Lean frameworks. Techniques that are effective making daily stand-ups work for distributed teams include:

  1. Deal with the time zone issue. There are two primary options to deal with time zones. The first is to keep the team members within three or four time zones of each other. Given typical sourcing options, this tends to be difficult. A second option is to rotate the time for the stand-up meeting from sprint to sprint so that everyone loses a similar amount of sleep (share the pain option). One usable solution that can be tried when distributed teams can’t overlap is to have one team member (rotate) staying late or coming in early to overlap work times.
  2. Identify and attack blockers between stand-ups. Typically, on distributed teams, all parties will not work at the same time. Team members should be counseled to communicate blockers to the team as soon as they are discovered so that something discovered late in the day in one time zone does not affect the team in a different time zone that might just be starting to work. One group I worked with had stand-ups twice each day (at the beginning of the day and at the end of the day) to ensure continuous communication.
  3. Push status outside the stand-up. A solution suggested by Matt Hauser is to have the team answer the classic three questions (What did you do yesterday? What will you do today? Is there anything blocking your progress?) on a WIKI for everyone on the team to read before the stand-up meeting. This helps focus the meeting on planning or dealing with issues.
  4. Vary the question set being asked. The process of varying the question set keeps the team focused on communication rather than giving a memorized speech. For example ask:
    1. Is anyone stuck?
    2. Does anyone need help?
    3. What did not get competed yesterday?
    4. Is there anything everyone should know?

This technique can be used for non-distributed teams, as well as distributed teams.

  1. Ensure that everyone is standing. This is code for making sure that everyone is paying attention and staying focused. Standing is just one technique for helping team members stay focused. Others include banning cell phones and side conversations.
  2. Make sure the meeting stays “crisp.” Stand-up meetings by definition are short and to the point. The team needs to ensure that the meeting stays as disciplined as possible. All team members should show up on time and be prepared to discuss their role in the project. Discussion includes the willingness to ask for help and to provide help to team members.
  3. Use a physical status wall. While the term “distributed” screams tool usage, using a physical wall helps to focus the team. The simplicity of a physical wall takes the complexity of tool usage off the table so the focus can be on communication. Use of a physical wall in a distributed environment will mean using video to moving tasks on the wall (after the fact a picture can be provided to the team). If video is not available, use a tool that EVERYONE has access to. Keep tools as simple as possible.
  4. Don’t stop doing stand-ups. Stand-up meetings are a critical communication and planning event, not doing stand-ups for a distributed team is an indicator that the organization should go back to project manager/plan-based methods.

Like any other distributed team meeting, having good telecommunication/video tools is not only important, it is a prerequisite. If team members can’t hear each other, they CAN’T communicate.

Stand-ups are nearly ubiquitous in Agile. I would do stand-ups even if I were not doing Agile. However despite their simplicity, the added complexity of distributed teams can cause problems. The whole team is responsible for making the stand-up meetings work. While the Scrum master may take the lead in insuring the logistics are right or to facilitate the session when needed, everyone needs to play a role.


Categories: Process Management

Handling Requests for Unnecessary Artifacts

Mike Cohn's Blog - Tue, 09/30/2014 - 15:00

The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted on the blog, here.

“Working software over comprehensive documentation.” You’ve certainly seen that statement on the Agile Manifesto. It is perhaps the most important of the Manifesto’s four value statements—working software is, after all, the reason a team has undertaken a software development effort.

It is also one of the most misused parts of the Manifesto. This is the quote people cite when trying to get out of all documentation, which is not what the Manifesto says we should value.

Some documentation on a project can be great. But most non-agile teams write too much and talk too little. Some agile teams go to the opposite extreme, but many seem to find a good balance.

Occasionally, though, a team and product owner may disagree on the necessity of a document—usually with the product owner wanting a document and the team saying it’s not necessary. I’ve found two guidelines helpful in determining how to handle requests for various artifacts, especially documentation, on an agile project.

Guideline No. 1: If a team would produce an artifact while in the process of creating working software, that artifact is just naturally produced.

This guideline covers essentially everything a team would want to produce while on the way to building a system or product. It includes, for example, source code. It also includes any design documents, user guides and other items that the team wants to produce for the benefit of the current team, future teams maintaining the software or end users.

Guideline No. 2: If an artifact would not naturally be produced in the process of creating working software, the artifact is added to the product backlog.

The second guideline is there to cover cases when the product owner (or any other outside stakeholder) wants an artifact produced (usually a document) that the team would not normally produce.

For example, suppose the product owner asks the team to write a document describing every table and field in the database. I’ve certainly seen projects where such a document has been extremely helpful. (In fact, I’ve both requested and written such a document before.) But, I’ve always seen projects where this would have been unnecessary.

If the team thought this database description document were helpful, they would produce it in the process of creating the working software. And Guideline No. 1 would apply. But if they don’t think this document is necessary, they won’t produce it. Unless, that is, the product owner insists, which is where Guideline No. 2 comes in.

If the product owner wants this document, the product owner creates a new product backlog item saying so. The team can then estimate the time it will take to develop this document, just like they’d estimate any other product backlog item.

Putting an estimate on creating the document makes its cost explicit. This forces a product owner to think about the opportunity cost of developing that document. The product owner will be able to ponder: This five-point document or five points worth of new features?

I don’t know which the product owner will choose, but this approach makes the cost of that artifact explicit, allowing it to be compared with the value of additional features instead.

I’d love to know your thoughts on this. How does your team handle product owner requests for artifacts the team wouldn’t naturally produce? What artifacts does your team find helpful? Please share your thoughts in the discussion below.

Handling Requests for Unnecessary Artifacts

Mike Cohn's Blog - Tue, 09/30/2014 - 15:00

The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted on the blog, here.

“Working software over comprehensive documentation.” You’ve certainly seen that statement on the Agile Manifesto. It is perhaps the most important of the Manifesto’s four value statements—working software is, after all, the reason a team has undertaken a software development effort.

It is also one of the most misused parts of the Manifesto. This is the quote people cite when trying to get out of all documentation, which is not what the Manifesto says we should value.

Some documentation on a project can be great. But most non-agile teams write too much and talk too little. Some agile teams go to the opposite extreme, but many seem to find a good balance.

Occasionally, though, a team and product owner may disagree on the necessity of a document—usually with the product owner wanting a document and the team saying it’s not necessary. I’ve found two guidelines helpful in determining how to handle requests for various artifacts, especially documentation, on an agile project.

Guideline No. 1: If a team would produce an artifact while in the process of creating working software, that artifact is just naturally produced.

This guideline covers essentially everything a team would want to produce while on the way to building a system or product. It includes, for example, source code. It also includes any design documents, user guides and other items that the team wants to produce for the benefit of the current team, future teams maintaining the software or end users.

Guideline No. 2: If an artifact would not naturally be produced in the process of creating working software, the artifact is added to the product backlog.

The second guideline is there to cover cases when the product owner (or any other outside stakeholder) wants an artifact produced (usually a document) that the team would not normally produce.

For example, suppose the product owner asks the team to write a document describing every table and field in the database. I’ve certainly seen projects where such a document has been extremely helpful. (In fact, I’ve both requested and written such a document before.) But, I’ve always seen projects where this would have been unnecessary.

If the team thought this database description document were helpful, they would produce it in the process of creating the working software. And Guideline No. 1 would apply. But if they don’t think this document is necessary, they won’t produce it. Unless, that is, the product owner insists, which is where Guideline No. 2 comes in.

If the product owner wants this document, the product owner creates a new product backlog item saying so. The team can then estimate the time it will take to develop this document, just like they’d estimate any other product backlog item.

Putting an estimate on creating the document makes its cost explicit. This forces a product owner to think about the opportunity cost of developing that document. The product owner will be able to ponder: This five-point document or five points worth of new features?

I don’t know which the product owner will choose, but this approach makes the cost of that artifact explicit, allowing it to be compared with the value of additional features instead.

I’d love to know your thoughts on this. How does your team handle product owner requests for artifacts the team wouldn’t naturally produce? What artifacts does your team find helpful? Please share your thoughts in the discussion below.

Is Agile Dead or Can Good Software Development Scale?

From the Editor of Methods & Tools - Tue, 09/30/2014 - 13:23
As Agile becomes widely accepted as a software development approach, many large organizations have adopted it, mainly in its Scrum form to reduce development cycle. There might be even a fair share of adopters that are trying really to apply Agile values. If the topic of scaling Agile has been discussed for many years and you can read the excellent books of Graig Larman and Bas Vodde on this topic. We have also recently seen the emergence of proprietary” approaches, like SAFE, to achieve this goal. At the same time, ...

Distributed Agile: Sprint Planning

#6 Make sure the telecommunications tools work.

#6 Make sure the telecommunications tools work.

In Distributed Agile: Distributed Team Degree of Difficulty Matrix, I described the many flavors of distributed Agile teams and the complexity different configurations create. While all things being equal, distributed team are less effective than collocated teams. Never the less, distributed Agile with teams spread across countries, continents and companies have become a fact of life. There are techniques to help distributed Agile teams become more effective. In an environment using Scrum, the first formal activities for most team’s is sprint planning. There are numerous techniques that can help make distributed Agile more effective. These techniques include:

1.   Bring the team physically together. Co-location, whether for a single sprint or some periodic basis, will increase the team’s ability to understand each other and know how to work together more effectively.
2.   Develop a sprint planning checklist. The process of getting together and planning is a fairly predictable process. Capture the typical preparation and meeting tasks and make sure they happen. Items can include booking rooms, securing video or telecom facilities, publishing an agenda with breaks and more.
3.   Review the definition of done. Ensure that everyone understands the organization’s definition of done before the starting to plan. The definition of done will help the team know the tasks they need to complete during the sprint to meet the organization’s (or product owner’s) process standards.
4.   Focus on the stories. Don’t let distractions get in the way of planning. Before beginning the planning session, review the process that will be followed with the entire team. Make sure that planning the next sprint is the only topic on the agenda.
5.   Ensure that the stories have been properly groomed. The stories that the team will accept and plan need to be properly formed and have acceptance criteria. This generally means that the stories that are most apt to be accepted by team (and a few more) need to have been through a grooming session. Make this a prerequisite for the planning meeting.
6.   Make sure the telecommunications tools work and have a backup. Distributed planning means that all of the team will be using the phone or video conference. Make sure they are set up and tested. Also always have a backup plan in case your favorite collaboration tool fails because sooner or later it will. Planning is a whole team activity and when the whole team can’t participate planning, it will lose effectiveness.
7.   Everyone should understand the big picture. Have the product owner provide an overview of the goals of the project, and how the current sprint will support those goals. Repeating the big picture will provide the team with a common touch point to validate progress.
8.   Use physical tools for interaction. Physical tools, like flip charts and card walls, can be difficult when many locations are involved in sprint planning. However, when possible, use physical tools like flip charts and whiteboard and then use webcams (preferable) and cameras to share data. Have one location scribe one story and then switch locations for the next story.
9.   Try multiple facilitators. When a team is evenly distributed between two locations consider having another scrum master act as a second facilitator to ensure everyone stays on track. Similarly, have the Scrum master rotate between locations to facilitate the planning session. This can be very effective in helping each location feel connected.
10.Remember that sprint planning is a team meeting. Make sure everyone is involved.

Sprint planning, done well, helps a team understand what they have to do in order to consider a story complete, both from a functional and technical perspective. Distributed Agile teams will need to focus on making sure that everyone is involved and a part of the planning process. Remember to plan for planning, because when you are on the other end of a phone or videoconferencing the tools, process and logistics can make or break the meeting!


Categories: Process Management