Skip to content

Companies

10 Things You Could Do When You’re Done Writing Code

Agile Management Blog - VersionOne - Thu, 10/09/2014 - 16:45

So you’re two-thirds of the way through your iteration and there are no more development tasks to complete. Nice work! Understandably, your instinct is to pull another story into the iteration, but doing so has risks and disadvantages. When you add additional work into the iteration, you’re increasing the batch size. This causes additional complication due to increased changes in the code base. It usually results in carryover, which has a demoralizing effect on the team. And it eliminates an opportunity to get feedback on the emergent product before additional work is embarked on.

Remember, the iteration was planned so that all members of the team can function at optimum efficiency, not so that the developers can program at optimum efficiency (Yes, there is a difference).

Before you peek into your product owner’s backlog and working on something outside the iteration plan, have a look at this list and consider doing one or more of these things instead:

1.  Refactor something you recently wrote
2.  Add unit tests to an uncovered area of code
3.  Find a technical tutorial on the Internet
4.  Offer to pair with a developer on another team
5.  Estimate open items in the backlog
6.  Create some automated functional tests
7.  Clean your desk
8.  Ask your product owner about the next release
9.  Help your product owner create acceptance criteria for items in the backlog
10. Implement a prioritized improvement suggestion from the last retrospective

This isn’t an exhaustive list. What am I missing? Let’s see how many more items we can add to it. Give me your ideas in the comments, or tweet them – @johnkrewson.

Categories: Companies

Function references in Swift and retain cycles

Xebia Blog - Thu, 10/09/2014 - 15: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.

Categories: Companies

Retrospective Plan from a new ScrumMaster

Growing Agile - Thu, 10/09/2014 - 14:00

It’s always great as a coach when you see someone take what you have taught them and really embrace it. Rushida Hendricks is a new Scrum Master at Liberty Health. This is the retrospective plan she created for her team’s fourth retrospective.

Sprint 4 Retrospective 791x1024 Retrospective Plan from a new ScrumMaster

What I love about this plan is that the bulk of the time is spent in Generate Insights and Decide What to Do, the most important parts of the retro.

She has allowed 20 minutes of buffer time in a 90 minute retro, which means no section needs to be rushed if an interesting discussion is happening.

I love the checkin since it focussed the retro on the team and their needs. A common mistake of new teams is to think the retrospective is for the Scrum Master.

Generate Insights follows on nicely from the previous activity, using the output from one activity as the input for the next. Again this is something that takes experience to get right.

There is a nice mix of individual and group activities to ensure that everyone is participating. Rushida is also using technique of having people write down there thoughts (e.g. in the close) before they share them, which works well for more introverted team members.

You can download the full plan here: Sprint 4 Retrospective Full

Categories: Companies

Demystifying the Language of Commitment

BigVisible Solutions :: An Agile Company - Wed, 10/08/2014 - 21:22

Making and keeping commitments is often a controversial topic within organizations. In my experience commitment-making is more challenging than it might seem on the surface and a lot of bad feelings and unfulfilled expectations arise because people lack some of the basic tools in the language of commitment. A commitment exists in language. “If you […]

The post Demystifying the Language of Commitment appeared first on BigVisible Solutions.

Categories: Companies

New Notifications Option

Agile Zen - Wed, 10/08/2014 - 19:59

The notification system now supports ignoring cards that are not assigned to you. Head to your settings page (top right when logged in) and click on the Notifications tab. Check the box below to only receive notifications for your cards:

Screen Shot 2014-10-07 at 4.27.37 PM

Jayme

Categories: Companies

Why does Agile Obsess about Product Features being 100% Done?

BigVisible Solutions :: An Agile Company - Tue, 10/07/2014 - 15:38

High functioning agile teams are able to complete stories in an iteration. Newer teams struggle, with stories spilling over from iteration to iteration. Why does this matter? Well, focusing on things being done is an effective approach to risk management. When something is 100% done, you’ve eliminated some risk associated with the development of your […]

The post Why does Agile Obsess about Product Features being 100% Done? appeared first on BigVisible Solutions.

Categories: Companies

Product Owner Decision Making

Growing Agile - Tue, 10/07/2014 - 14:11

The most important thing a Product Owner needs to do is say NO. If they don’t it results in a huge backlog with lots of items, and usually pressure to deliver more than is realistically achievable.

Many people fail to realise that Scrum is not about building the same stuff faster. The Chaos report tells us that 60% of features are never or rarely used. The point of Scrum is to identify this 60% early and to not build them in the first place. If you do this, you have doubled your productivity by doing nothing except saying no.

I drew the following PO decision tree to help new PO’s understand how often they need to say no.

 

 

PODecisions Product Owner Decision MakingIf you are still not convinced that you need to say no, here is a simple exercise based on queuing theory:

Cycle time (the amount of time customers wait for a requested item) is related to the length of the queue. Think about grocery shopping or the bank. The longer the queue, the longer you have to wait right?

What happens for you when you wait in a long queue? Do you enjoy it? I usually start tweeting about how poor the service is icon wink Product Owner Decision Making

At this point I’m hoping you agree – a short queue is a good idea.

Now consider your current queue. Either your backlog, or your ticketing system, or your bug tracker – whatever holds the list of all the work your team needs to do.

  1. What is the current size of that queue (open or in progress items)?
  2. What is the input rate. i.e. how many new items are created each month?
  3. What is the output rate i.e. how many items are closed each month?
  4. What will your queue look like in 6 months time
Let’s take an example.

Imagine your ticket system currently has 1000 items open. 100 tickets are opened per month and 50 are closed each month.

In six months time your queue will be 1000 + (100 – 50)*6 = 1300

That means customers will be waiting even longer. On average they will wait 26 months for their ticket to be solved! (queue size / output rate) Chances are they won’t be a customer anymore after that amount of time.

What if you only wanted customers to wait max 1 month?

In this example, you would need a max queue size of 50 (monthly output rate).

If you wanted your queue size to be 50 in six months time, what would you need to do? For the sake of this example you can’t just throw more people at it. (And usually that is not an answer).

You would need to say no to some requests.

How many would you have to say no to?

Currently you have 1000 requests. You will get another 600 in the next 6 months, so in total you have 1600 requests.

Your team can do 300 requests in 6 months, and you will allow 50 to be in the queue. So you can accept 350 requests.

You need to say NO to 1250 out of 1600 requests, or 78% !!!

You might think this is unrealistic, but what is unrealistic is believing that you can service 1600 requests. Don’t fool yourself or lie to your clients. Start saying no, so that you can say Yes to the 20% of the work that is essential to your customers and products.

Categories: Companies

Why 'Why' Is Everything

Xebia Blog - Mon, 10/06/2014 - 21: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.

Categories: Companies

Agile Enablement: Leadership Everywhere is Essential for an Agile Organization

BigVisible Solutions :: An Agile Company - Mon, 10/06/2014 - 20:19

Leadership is an essential ingredient for a high-performing, self-organizing agile team, but not necessarily in the way leadership is traditionally envisioned, with a designated individual providing the leadership. On agile teams, leadership is expected of all team members. This is a relatively new and potentially challenging idea to grasp, but once mastered can lead to […]

The post Agile Enablement: Leadership Everywhere is Essential for an Agile Organization appeared first on BigVisible Solutions.

Categories: Companies

How to create a Value Stream Map

Xebia Blog - Mon, 10/06/2014 - 09: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.

Categories: Companies

Integrating Geb with FitNesse using the Groovy ConfigSlurper

Xebia Blog - Fri, 10/03/2014 - 19: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.

Categories: Companies

UXSouthAfrica – UX and Agile

Growing Agile - Fri, 10/03/2014 - 10:00

Today we are doing a talk at UXSouthAfrica on UX and Agile. This topic has been a favourite of ours for a while. We believe strongly that agile and UX can work together very well. Unfortunately what we see most often is a sprint of UX running ahead of a sprint of dev. This is NOT what we mean by agile UX.

Our talk explains the differences between Traditional UX, Agile UX and Lean UX. We also provide some tips for UX people wanting to try this out. You can get the slides on slideshare.

Else you can watch the video:

Here are some links to interesting blog posts on the topic:

This is a great newsletter on the topic of UX: The Agile & Lean UX News – be sure to subscribe!

Categories: Companies

New Navigation & More Workspaces

Pivotal Tracker Blog - Thu, 10/02/2014 - 21:25
Where’s my cheese?

As we move ever closer to coming out of beta with the new Tracker UI, we’ve changed how you navigate Tracker in the header, making it consistent for everyone.

ProjectsDropdownClassic

All the items in the header are click-able, and most have drop downs with more options. For example, click the Tracker logo at the far left, to go to the Dashboard. Click a little further to the right on the project name, to see the Projects list. Also, when you click your username, you’ll see that’s where Reports have moved to.

UserMenu

You can also access the Projects menu in the Dashboard by clicking PivotalTracker in the logo at the top left.

Speaking of the beta, if you haven’t tried it, please do! When you’re in a project, you can switch back to the original Tracker via the option under your username at the top right. Or you can can change between beta and original in your Profile.

Workspaces Galore

DashboardwithWorkspacesThe majority of customers are now using the Tracker beta and we’ve received a ton of positive feedback on how useful you’re finding the Multi-project Workspace.

We also heard that many of you wanted more! You asked to be able to have more than one Workspace, to help you focus on particular sets of projects. Now you have just that in our latest update.

ProjectsDropdownBetaYou can create Workspaces in a couple of spots, such as the Projects drop down shown above. If you click Show All Projects or Show All Workspaces, you’ll go to the Projects page (below), which now includes Workspaces.

ProjectsPageThe Projects page is another handy place to create and manage Workspaces. Click Settings to the right of any Workspace, to rename or delete it. You can also click Workspace and Project names to go to them.

We hope multiple Workspaces (as well as performance improvements and bug fixes) make the beta a bit better or tempts you to try it! As always, please share your feedback via the in-app feedback button or email, and follow us on Twitter for more.

The post New Navigation & More Workspaces appeared first on Pivotal Tracker.

Categories: Companies

Corporate Values: Really Valuable, or Really Just a Poster?

Agile Management Blog - VersionOne - Thu, 10/02/2014 - 17:06

You hear about the agile values and they seem to make sense, but what the heck is a value system? And how do you use value systems in your daily work? Do your values really help you do your job better, or are they really just a poster in your office kitchen?

When I say values, I’m talking about beliefs that guide behavior – as opposed to the term value meaning ‘the benefit of what is being produced.’ In software we use both “agile values” and “business value,” but they represent different things.

Corporate values have peppered company literature for ages.  These value statements are important expressions of the community and culture within a company.  In larger organizations, however, those values are often so abstract that it’s tough to impact a team’s work.

The notion of a value system to guide agile software development emerged in Kent Beck’s inclusion of values with the introduction of Extreme Programming (XP) in the late ‘90s.   A similar set of values was added to Scrum soon afterward. And soon after that, the Agile Manifesto was born. It brought software teams a straightforward value statement that today remains a powerful influence on the behavior and success of agile software development teams all over the world.

The concept of a human value system has been reasonably well studied in psychology since the ‘50s, but before 1999 (when Kent posed the question, “What is it that we value?”), developers simply didn’t talk about values – only the work at hand. People brought abstract, personal values in to work with them, which may have influenced behavior lightly.  This introduction of a value system was one of the most innovative parts of XP.  The XP values are Communication, Simplicity, Feedback, Courage and Respect. With the Agile Manifesto, that contribution expanded to the broader software industry and beyond, opening a new focus on behavior and improving the way we do things.

Let’s back up and define the agile values…

Watch this video: “The Agile Manifesto – 4 Agile Values Explained”

Sound familiar?

You’ve probably seen these agile values introduced in agile training, and they are easy to learn. They also read well on posters. But how do they affect you every day, every sprint, every release?

The utility of the value system is often lost to the intense focus on the agile frameworks and practices. Back when XP was still the most common agile approach, I gave a popular talk that included asking the audience, “What is XP?”  Invariably, it would take many minutes and an awkward silence after all of the practices were exhausted for someone to timidly mention the values.  Most certified Scrum people are not be able to articulate the Scrum values.  Of the roughly 150 words squeezed into the official Scaled Agile Framework® diagram, only one of values, Code Quality, made the cut (alignment, transparency, and program execution are the omitted three).  We have a long way to go to appreciate the important role that values play in enabling teams to be empowered to adapt their practices and maximize their delivery.

So, why are these values so important?  Aren’t we doing OK with the values being the footnote they are?

To see the answer, one needs to look no further than the frustration expressed around the dogma of agile.  A common complaint of Scrum team members is an almost irrational commitment to follow the rules of Scrum blindly.  Ironically, one reaction of the Scrum community to SAFe™ is that it is overly prescriptive in how organizations should scale Scrum.  In both cases, an increased focus and incorporation of the values leads teams to a better place.

In the absence of shared values to guide the adaptation of our practices, teams are left to resort to static rules to guide their behaviors.  We see silly arguments like “Should the Product Owner participate in the Daily Scrum?”  In the context of the Scrum values (Focus, Courage, Openness, Commitment and Respect), a team can answer that question easily and optimally by themselves.  We don’t need to enforce consistent practices, as long as teams apply the values to their situation.

Let’s explore some specifics 

The agile values system can guide daily decisions about working through problems with teams and individuals in a way that corporate values may not be able to.  Any problem we are trying to solve can be addressed with more rules and process, more contracts, more documents, more upfront planning.  Those are our traditional, comfort-zone, status quo solutions.  I can almost guarantee that in an early sprint retrospective with a new agile team, some of the feedback will be, “Had we spent more time documenting up front, we would not have had this problem.”

There will be times where those items “on the right” in the Manifesto will be part of the solution to our challenges.  But a commitment to our values will drive innovative solutions that better support our use of agile.  Examples include the increased use of tele-presence technology with distributed teams — reconstructing our workspaces, reconfiguring teams, and even relocating people — and collaborating with people we didn’t even realize were involved in, or affected by, our work.  The values will guide us to solutions that enhance agile, rather than contradict it.

One of my favorite examples where the values guided the solution to a problem was an SDLC compliance change at a very large financial services company.  Existing SDLC practices required numerous artifacts to be delivered within each phase of a project.  Requirements documents had to be signed off during the requirements phase, prior to design, etc.  The agile advocates needed this process requirement changed to empower agile teams to deliver shippable increments in each sprint.  But this needed to be done in a way that was still compatible with the majority of project teams who were still following the phased approach.

So, rather than create a big conflict, demanding that the whole process be changed, a simple change was made.  Audit artifacts are still required for the business, but teams have discretion as to WHEN artifacts get produced.  All of the artifacts are required when they close projects, but the team decides when it is optimal to do it. They don’t have to sign off on a Requirements document in the beginning of a long plan. Requirements can be modified over time, and they can furnish a signed-off Requirements document at the end. This moved the organization closer to the Individuals and Interactions value, while respecting the importance of Process and Tools in the broader organization.  A dogmatic stance on Scrum practices would not have been so open to that solution.  Later, further updates gave teams more discretion of WHICH artifacts were valuable enough to produce, further empowering the teams for continuous improvement.

So, the next time you’re in your Daily Scrum or Retrospective – or even just solving a problem – reflect on what is being talked about. How are teams and individuals working together to identify solutions? As you move across release and process design (teams and programs), pull out the agile values and assess whether your decisions and those of your teams reinforce the agile values or diminish them. Are they helping the organization make decisions that drive working software?  Use the values to guide your solutions and improvements.  If values aren’t helping people do their jobs better, why bother? At that point, they are just poster fodder!

Categories: Companies

Putting Down the Tools

Agile Zen - Tue, 09/30/2014 - 21:41

This is a guest post from Marcus Blankenship.

Putting Down the Tools Avoiding the #1 Mistake All New Software Managers Make in a Crisis

Yes, we’ve all done it.

I’ve done it. My managers have done it. And most likely, it’s the default setting for many battle-worn team leads.

In those crisis moments when expectations are high, everything is going off the rails, and the deadline was yesterday, all new software managers will utter one fateful sentence.

"It would be so much faster if I just did this myself."

Then they pick up the IDE, close the office door, and retreat into the code.

What they don’t realize is that they’ve just kicked off a chain reaction of negative work practices that will plague their team for months.

Save Yourself

As you probably understand all too well, the programming world is full of fires to extinguish. No matter what your company’s size or specialty, you are going to hit many, many pressure cooker days.

It’s up to you to anticipate the inevitable before it happens and make a firm, conscious choice not to try to code your way out of a crisis.

Why We Make This Classic Mistake

Making the switch from programmer to team lead can be flat out awkward at times. You’ve gone from playing in the orchestra from leading it, which really shakes up your identity.

The most significant shift comes with the realization that you’re no longer a production unit, but you’re still working in an industry that values production. If you’ve always taken pride in the tidy transaction of being paid for your output, management is a strange new world.

Mixed Messages

First off, while promotions are a much-coveted status symbol, they carry a built-in mixed message. It’s as if your company is saying, "You’re such a great programmer! Now let’s have you do less of that."

Doing less coding often feels like you’re doing less altogether or that you’re not as important to the company, especially when you’re just learning the ropes.

Dependent on Others

Then there’s the new reality of how production happens. As a programmer, your brainpower and clever workarounds could conjure magnificent code from your fingers.

The programs you created could keep manufacturing production humming or bring it to a standstill. Entire businesses hung on your creations.

Now you’re dependent on other people to create the code that works this magic. And making the switch from creating your own technological incantations to supporting other people’s efforts really feels awkward for a while.

It Gets Worse

That clumsy beginner’s feeling gets cranked up when you face the new aspects of team dynamics and the reality of being without your most powerful weapon: your ability to code.

But you really get triggered by array of new expectations staring at you, like:

  • Figuring out your boss’s agenda
  • Assigning work to former coworkers
  • Dealing with morale speed bumps
  • Steering through software quality problems

Stepping into a new management role can feel like stepping into a plane’s cockpit without any flight training. There are all these complicated, unfamiliar dials and gauges you don’t understand, and you don’t know if that blinking light means an engine has failed or the coffee’s ready.

In order to escape this anxiety loop, many new managers fall into one of two patterns:

  • Code less, but indulge their coding desires by putting out fires and debugging whenever possible.
  • Code even more intently, blocking out team members and undermining their credibility as a leader.

Each of these positions is a pattern that will cause you to fail.

Let me say it again. Retreating to the position of "I’ll do it myself" isn’t going to save you any time or frustration. It’s only going to crank up the problems.

## I’ll Do It Myself’: Say Hello to a Cascade of Problems

Once you’ve uttered those fateful words, you are no longer doing the job you were paid to do: leading. And if you’re not doing your job, especially when your team needs your leadership most, then no one is.

If you follow through on your natural desire to just do it yourself, you’ve chosen to avoid doing the following critical items:

Communication

Checking in with your team members and other departments is the heart of your work. But chaining yourself to your computer stops that cold. Suddenly, you’ve cut off any team discussions about quality, progress, or individual development. Everyone loses.

Connection

Jumping in to correct someone else’s work not only short-circuits their learning process, it teaches them to do substandard work. Pretty soon they only turn in partially completed work because they figure you’ll just redo it anyway.

"Why bother?", they think. They lose their drive, you lose their trust, and projects start to suffer.

It’s like a conductor wrestling the tuba away from the tuba player.

Momentum

When you move back into production mode, there’s no one available to keep team moving forward. Essential work like status updates, work review, and new project preparation is completely out the window until you pick your head up.

You’ve just traded away hours of non-replaceable time and energy that should have been devoted to doing the job you’re hired to do. And when you get back to the work that’s been piling up on your desk, you’ve got to dig out all over again.

Sustainability

Let’s be honest. It feels great to be a hero, swooping in to save the day with a brilliant solution. But the cost is just too high.

A "quick fix" always takes much longer, turning your one-hour job into six hours (or more!) of mind-numbing panic. While you code up a fix, your resentment and exhaustion build and you’re teaching your team to depend on your last-minute efforts to bail them out instead of their own skills.

Management Skills

Running to your comfort zone feels safe, but it’s a very limited strategy that keeps you from making the changes necessary for you to be a good manager.

Trust me. Take a chance, drop the IDE security blanket and interact with your team instead.

Best Practices for Crises

While you’re waiting for your team to complete their work, you don’t need to sit passively or beat them with the boss stick. Here are a few tips that will keep you sane and your team on track.

Don’t Do it Yourself

If there’s a problem that you desperately need to rework, *don’t do it yourself. Grab a programmer and say, "Let’s review this code together to fix it."

Sure, you just scratched your itch by getting involved, but you’ve also established much-needed rapport and created up a teaching moment–for both of you.

Communicate

Panicked about a deadline? Get a status update from the programmers, adjust the workload if needed, and contact the client (or your boss) to give them an update.

Once again, you’ve opened lines of communication and placed your focus on the overall project, not just your team’s to-do list or your stress.

OK, Go Ahead And Code…

Can’t keep yourself away from temptation? Fine. Then code. But don’t code anything that will be used in production.

I cannot emphasize this enough. If you absolutely, positively can’t resist, then choose a project that is on the back burner. You don’t want to muck up a project in process.

This Is About the Long Game

Great management practices depend on a solid, thoughtful foundation created outside the heat of crisis. But it’s worth remembering that reputations are earned and character is uncovered during crucial, adrenaline-filled moments.

Remember that your purpose as a manager is to create a team that is capable of producing excellent code.

In those instinct-driven moments, especially in beginner’s panic, please take a step back. Avoid this classic management blunder.

About the Author

Nearly 20 years ago I made the leap from senior-level hacker to full-on tech lead. Practically overnight I went from writing code to being in charge of actual human beings.

Without training or guidance, I suddenly had to deliver entire products on time and under budget, hit huge company goals, and do it all with a smile on my face. I share what I’ve learned here.

Categories: Companies

15 Useful Pacts for Agile Teams: An Agile Team Creed

Agile Management Blog - VersionOne - Tue, 09/30/2014 - 13:49

The Agile Manifesto values “Individuals and Interactions” over “Process and Tools.”  I suspect it was no accident that this was listed first.  Lack of communication, miscommunication, or the mistaken presumption that communication has occurred, are the root cause of many problems.  Yet, we still focus much discussion on the process and tools.

  • When and how do you conduct a certain Scrum ceremony?
  • Are you practicing pure Scrum?
  • Which agile tools do you use and why?
  • How do you use the tool?
  • What agile metrics are you using and how?
  • What best practices exist?
  • And lots more concerns and questions about how to “do” process…

However, most all change transformations to “be” agile struggle with organizational culture and many organizations and teams continue to fail to reach their full potential because of issues related to “individuals and interactions.”

Teams are the heartbeat of agile development.  It’s the people that produce business success.  Even when the organizational culture embraces agile values, the teams must also address their individuals and healthy interactions among them to maximize value.  This takes time and effort to mature.  I find we mistakenly assume that since people know each other already and even “behave” nicely, they think they can skip over the team-building activities.

Simply gathering individuals together and assigning them the label of “team” does not make a team.  Each team is comprised of unique personalities and thus there is no cookie-cutter best answer for every team.  Each team must find its own way and navigate the uniqueness of each individual to determine the best way to handle interactions that work for their team dynamic.  There should be “pacts” that everyone on the team agrees to.  If there are dysfunctions (egos, prima donnas, passive aggressive behavior, apathy, poor listening skills, a presumed hierarchy, and so on), then the challenge is an order of magnitude that’s much more difficult.  Each team is a unique, dynamic system, subject to changing moods and their environment.

Sadly, some agile teams never evolve beyond a collection of individuals who meet together at the prescribed Scrum ceremonies and then return to work independently with a focus on their individual tasks only.  Maybe the ability to track their work has improved, but they have failed to recognize and harness the true potential that comes from working as a high-performing team.  Perhaps you have seen teams who are full of energy and so you recognize the power of teams?  So, why do some teams never get there?  There are multiple factors that influence agile and Scrum teams.

Let’s assume that the organization’s leadership values the power of teams and has a supportive culture and vision in play.  So what can be done within the team to ensure that it sets a solid foundation for growth and success?

During the team forming stage, it is important for the team members to openly discuss behaviors and expectations.  There is great value in recording those discussions as a reminder to the members when they do encounter problems.  But, they need to dive deeply into what each member truly believes and feels.  Because what you believe and how you feel directly determines how you will behave.  These team discussions must go beyond the process-mechanics agreements such as what time to meet.  They need to communicate something more of an “agile team creed” or list of pacts they make with one another. Team members must be comfortable sharing their fears and concerns.

Having an agile team creed is a great starting point for deep team discussions to root out true beliefs.  It captures cultural expectations and behaviors for the team which I believe lay the foundation for a great agile team.  Here is my list of 15 useful pacts agile teams can make.  I call it the Agile Team Creed.

Agile Team Creed

Has your team had these deep conservations about what they believe?  Would they agree with these items as part of their Agile Team Creed?  If not, why?  Perhaps, it reveals a cultural issue that needs attention.

Categories: Companies

New Connections Functionality Now Available

LeanKit’s new Connections functionality has been released to all Portfolio Edition accounts. Find out how this enables you to track and manage work distributed across multiple teams and boards — without losing sight of the details. For some time now, LeanKit has provided the ability to create drill-through relationships. This functionality enabled you to establish parent-child associations between a […]

The post New Connections Functionality Now Available appeared first on Blog | LeanKit.

Categories: Companies

The Wonders of Workspaces

Pivotal Tracker Blog - Mon, 09/29/2014 - 19:43

Visibility is a wonderful thing. Making your team’s work transparent lets every stakeholder judge current status and progress at a glance. This transparency also reveals impediments – is one story blocked by another? Is something holding up progress? Are some activities turning into bottlenecks? Seeing a snapshot of a team’s current status and progress is also a conversation starter: “I have a question about this story – oh, I see that Joe, Debbie and Mary are all working on it, I will ask them”.

MPworkspace

Example multi-project workspace. Note the color coding for projects across the top of each panel & in the sidebar.

Tracker has provided visibility into individual software projects for years. But your organization probably isn’t working on one simple project. Maybe you have more than one code base for your product, for example, a back-end server, a front-end web app, a mobile app. You might have multiple versions of some of those, too. Oh, and there’s a lot of supporting work to track: DevOps activities, testing across multiple code bases, UX design. It doesn’t make sense to shoehorn everything into one project. But managing multiple projects can get pretty complicated. The beta version of Tracker offers an approach that works well for many teams that have multiple products or projects to manage: workspaces. Tracker users have the option to view and manage several Tracker projects side-by-side in their multi-project workspace. Let’s look at the multiple joys that multi-project workspaces have to offer. Improved Visibility When you create a multi-project workspace, you can load relevant panels from all your projects into one Tracker session, and see progress in all of them at a glance. If you’re working on stories in more than one project, you can see all your current stories in all projects in the My Work panel. See the screenshot above for an example My Work across multiple projects.

Select color in the single project view

Select color for a single project

Manage workspace to easily update project colors

Manage workspace

If your team currently uses a single project for all stories, and manages different tracks with epics, consider giving each track its own project. The multi-project view gives a simpler high-level view, with color coding to distinguish project panels. Click the icon at the top left of the sidebar, above the Add Story button, to manage your workspace. As well as adding and removing the Projects you would like in your workspace there, via the “add/remove projects” dialog, you can change project colors. You can also customize your colors in single project view by clicking on the color icon at the top left. Easy, Flexible Organizing Let’s say your team creates projects for your front-end code, your back-end server, a mobile app, DevOps chores, and system testing charters. You’re a tester who gets involved in all of these (yes, multi-tasking is bad, but cross-functional knowledge and involvement is good!) You add all these projects to your Tracker workspace so you can see the big picture. Tracker remembers what panels you had open the last time you used your workspace, and in what order, so you don’t need to tweak your panel layout each session. You start testing delivered stories in the front-end project, because that release is coming up soon. As you are testing, you discover a new bug in the back-end code. Without having to switch to a different Tracker view, you add a bug story to your back-end project Icebox. While looking at the back-end project’s Icebox, you realize that a bug story you entered earlier is really a problem on the front-end. You simply drag that story over to the front-end Icebox panel where it belongs. Before returning to testing your front-end stories, you see a new in-app notification. Clicking on the story in the notification, Tracker opens a story in the mobile app project. A new feature you’re keen to test has just been delivered, so you make a mental note to check that out later. A little while later, you’ve caught up with testing the front-end stories. Your next priority would be to test delivered back-end stories, but you can see nothing has been delivered yet. There is also some exploratory testing to do on the front-end, but you can see that a developer pair has been cranking through the test charters in your system testing project, so you go test that fun new mobile app feature. Managing Dependencies There are many ways a story can get blocked. It may be waiting for a design element or a change to an API. It might be blocked by a story in the same project, or one in another project. We like to make this visible by putting a “blocked” label on the story, along with a link to the story that’s blocking it. For example, if it’s waiting for a design story, the label may be “needs design”. If a delivered story can’t be accepted yet due to a dependency on another story, it gets an “accept blocked” label. The blocking story also gets a label and a link to the story it’s blocking. This information stays front and center for everyone on the team. This kind of visibility is even more crucial when multiple teams work on the same or related products.

Story dependencies made visible with labels and links to stories in other projects

Story dependencies made visible with labels and links to stories in other projects

Since Tracker allows you to search across all projects in your workspace, you can bring up all stories with a particular label. They’ll display in a panel ordered by project. Promoting Conversations Along with multi-project workspace, Tracker beta provides other features to enhance communication. Each Tracker user can customize their own settings for in-app notifications. The bell icon at the top of the page indicates the number of unread notifications. When you open a notification, you can click to open the story, regardless of what projects you currently have open. Project members can quickly get attention from others with @mentions, which get special highlighting. Then, if necessary, they can have a face-to-face conversation about the story or epic. Finding Stuff Faster When you’re involved in multiple projects, it can get hard to remember which stories are where. In Tracker’s multi-project workspace, the searches you request will retrieve matches in any of the projects in your workspace. It saves time, plus you’ll see stories in other projects that may be related.

You can search across all projects in your workspace

You can search across all projects in your workspace

I often click on a label for a quick overview of all the stories in my workspace with that label. We’ll be enhancing the ability to organize your work with saved searches in workspaces later on.

newBetaButton

Click the button to try beta!

If you haven’t experienced the joys of the multi-project workspace, click the button at the top of your project page to switch to Beta. When you get there, check out the Beta Overview panel (accessed via the Help & Updates menu at the top right of your Tracker window) to see how to configure your workspace. Enjoy improved visibility into project progress and impediments, and better communication with your teammates. In the coming weeks, we will be adding more capabilities including the ability to create multiple workspaces, each with a different set of projects. Are you already using a multi-project workspace? We’d love to hear how you’re making the most of this new feature. Please comment and share your experiences.

The post The Wonders of Workspaces appeared first on Pivotal Tracker.

Categories: Companies

Using the Understanding of When SAFe Is Heavy Is How to Use It Properly a Organizations Smaller Than It Was Designed For

NetObjectives - Sat, 09/27/2014 - 21:24
Note: this blog is part of the Series of Blogs on Scaled Agile, Lean and SAFe  I’ve had a very interesting few weeks. At Net Objectives we’ve always put the customer first, even if this meant not offering a technology we were certified to teach. This has also made us unpopular with several of the certifying bodies that we’ve worked with.  The Scrum Alliance didn’t like when we said you needed...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

What Is It That Can Make SAFe Heavy?

NetObjectives - Sat, 09/27/2014 - 20:24
Note: this blog is part of the Series of Blogs on Scaled Agile, Lean and SAFe  Many of the detractors of SAFe say it is heavy. But it is only heavy if it is more than is needed. For example, prior to 3.0, SAFe had a Hardening, Innovation and Planning Sprint.  People would say "hardening" (i.e., when you just work on bugs) is not an Agile concept.  I would say, "when you need it, it is."  In...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies