Scaling the PO team

Second session was planned to be another session with Alistair Cockburn however, he choose to ignore the official session title and instead he conducted an interactive activity demonstrating the power of iterative development and effectiveness of an adaptive process.

after that Ive joined a session focusing on the role of the PO in a scrum process and how to scale this position without damaging the entire process.

The role of the PO in a scrum team is to represent the client. the PO is responsible of maximizing the ROI, i.e. he’s the one responsible for generating $$$. Specifically the PO is in charge of grooming the product backlog, which includes among other, writing user stories, prioritizing them and keeping track on what is getting build. The important thing to remember is that this is an active role, stories are not invented from thin air, they are discovered by talking with users, customers and sometime even the developers. A good PO will actively manage the backlog, he will keep priorities straight, refine stories as new knowledge is gained, remove less important stories and add new ones.

The key point of being a PO which is sometimes missed is that the PO should consider himself as part of the team. When a PO works in disconnection from the team, things will usually not go smoothly optimal. For example while in the Scrum “rule book” the PO approves stories during the demo at the end of the sprint, effective PO’s do not wait for it. they actively review and approve progress during the sprint work. after all why wait?

Scaling the PO

But sometime one person is not enough to effectively cover all the responsibilities of the PO role. and the big question is how to scale that role. Like anything else there is not a single answer on how to correctly scale the PO role, each method has its own strengths and its own risks. the key for success like anything else in life is to always manage the risks and be on the lookout when things are not going as they should.

One way of scaling the Po is to divide the by area of responsibility. i.e. one person (or more will work closely with the customer) and one (or more) will work closely with the team. Another option is to split the work more naturally according to the product technical components. but no matter how the work is split its crucial to first achieve good communications channels between the people functioning as PO’s. Normally a PO team will much higher level of cooperation than other teams to succeed.

another tip for scaling the PO role is to adhere to agile values, i.e. always inspect how the team of PO function and to improve. It is also possible to use a modified scrum process in order to manage the work inside the PO’s team.

When not to Scale

but the most important tip of this session was when to chose not to scale. Sometime organizations are scaling the PO not because they actually need to, but because there's an underlying dysfunction which was not recognized. for example I've seen a PO which spent so much time in customer relations, that he didn’t have time to help the development team. naturally the team complained, and suggested to add more personal to the PO. Only after sitting with the PO and raising the team issues, did we realize that the PO did have time but he didn’t fully understands what was required of him.

So before scaling, take a good look, maybe scaling i not the answer. maybe just maybe there’s a better alternative.

Read more »

Posted in: Events,Scrum,Team System

MSTest – ExpectedException and exception message.

Since this is my first blog post ill start out small enough.

Recently we have migrated our unit test from NUnit into MSTest. Although by large the transition was quite smooth, one of the more annoying issues is the different behavior of the ExpectedException attribute.

An intended design or an oversight by MS?

I would (wishfully) think the latter is the case. But in any case I would say its a Mistake.

In any case, since MsTest does not support asserting on the exception message, we had to revise some of the tests. The revision itself is quite simple, just need to wrap the test code with try catch clause. Something like:

[TestMethod]
public void SomeTest()
{
    try
    {
        //The test code:
        //...
        //...
        Assert.Fail("We should not get here");
    }
    catch(SomeExceptionType ex)
    {
        Assert.AreEqual("Expected Message",
            ex.Message);  
    }
}

However after doing this for a couple of tests we have managed to come up with a slightly better pattern:

[TestMethod]
[ExpectedException(typeof(SomeExceptionType))]
public void SomeTest()
{
    try
    {
        //The test code:
        //...
        //...
     
    }
    catch(SomeExceptionType ex)
    {
        Assert.AreEqual("Expected Message",
            ex.Message);
        throw;
    }
}

Although the difference is quite minor, still we found the second version much more expressive and readable.

To conclude, there’s a lesson to be learnt here. When trying to replace a well used framework its best to make sure that the transition will be as easy as possible (Unless you are MS and can get away with this).

Read more »

Posted in: Team System,Unit Test Patterns