Advice for an assignment I am transitioning to Agile.

[Anadi Misra]

Hi,

I have mostly had all my agile experiences as developer and scrum master in projects where my scrum was always a feature team. I have recently moved to PO of a team we have which has the responsibility of planning and executing releases; improve the platform itself in terms of testing, builds and deployments to reduce release cycles(the long waterfallish release cycles has been a pain for the customer) and hopefully the time needed by developers to complete a story - what they percieve as overall readiness of the platform.

The problem however is a bit more complicated:

This team unfortunately had the daily 5 minutes standup as the only Agile practice they were following - so there hasn't really been an iteration planning ever before, and they lack knowledge of what scrum is- I am solving that by the good ol' agile education lunches; 1 hour introductory sprint etc.

I however get stuck when planning releases and estimating stories for them. A major chunk of stories will be repeated work related to the release cycle. This includes testing, SCM, SI tasks etc - the volumes of which cannot be really known until I go to the demos of each of these feature teams (9 in my case). and the day after this big demo day - I have to start with release cycles. So the natural way for me here was to do all the release cycle activities continually just as sprints have been.


I have thought of the following improvements to ease out things a bit; please do let me know if there can be more added

1) - Migrate test cases to Selenium.
2) - Create a Selenium GRID.
3) - Make feature scrums also use the same selenium based setup to do testing of new user stories - i.e. make them estimate creating the selenium tests when estimating a story and add a successful run of the test as one of the cluases on Definition of Done.( we currently rely on Unit, Integration tests in builds and manual testing of the feature by a scrum tester for completeness)
4) - My scrum keeps updating regression, system and EndToEnd tests as and when required.
5) - Do daily merges of the change set to a branch only when all tests for a change set are done - build it again there and create a deploy ready distribution and run nightly regression, EndToEnd system tests.
6) - Have a dedicated UAT environment available so the customers can run UAT more continually and thus reduce the feedback cycle.

The idea as I see it is that if a regression breaks it rather be within a sprint where it is easier to ask featurre teams to reprioritize work and fix it; get even more quick feedback by updating the UAT env with a new stable diistribution the moment you have it and inform customers so that they have a UAT done for the stories even before there is a demo,So in short get feedback earlier than demo. ( I cant really wait until the demo to allow a stakeholder to provide a feedback which results in more changes).

Anything more to add to this list? You can aruge why to keep a branch but thats a platform limitation - the core prroduct we work upon is not just J2EE code to write; there are a lot of XML templates and the like to be created before a feature for the site can be made workable without breaking builds or regression tests.

[Ilja Preuss]

If I understand correctly, you are the PO of those teams? And those are supposed to be Scrum teams?

First, estimation is not your job at all. It's the teams' job.

Second, all those items in the list look like implementation details to me. Having those come from the PO is a serious impediment to the self-organization of the teams. You should think about what *business value* you care about. Aks the teams how they are going to give you that value.

Of course the teams might need some coaching on how possibly to do what you are asking them to do. Notice, though, that if you give that help, you are leaving your role as a PO and go back into the role of a SM/Coach. Not sure it's a good idea for you to do that - perhaps it would be better to get someone else to fill that role.

[Anadi Misra]

Hi,

Yeap you are right these are implementation details; but, I am stuck in a PO/Coach kind of role for commercial reasons. My intention here is to have a list ready which I can give as inputs to the team during there discussions of making releases leaner than what they are today.

I think I have to agree that me trying to estimate them will be a big flaw. I should leave that estimation completely to the teams.

But the intention of this post is to know what practices help in making the release cycles lean and shorter in duration. It is tough to get into release management stuff when you have been a developer mostly - so I am looking for some inputs through this post that when it comes to Agile what are the good SCM, Build, Test and most importantly release execution practices.

[Ramesh Donnipadu]

Anadi,

From your description, it looks like your team need a good coaching on Agile practices, Lean thinking. They need some help on estimating, continuous build and release management and other engineering practices. It is good that you are trying to fill that role to some extent, but it leads to a conflict of interest with your official duties.

Coming from a Development and SM background, it may be very tempting not to interfere, but you need to do some unlearning and focus only on market research, product strategy, road map and business value.

[Pallav Bora]

Well some thoughts on smoothening sprints (or iteration , for that matter).

Its good to have a list of things would be acomplished in the comming sprints (read Poduct Backlog in Scrum speak.). Now size the product backlog items. The "Sprint Backlog" should consists of only items from Product Backlog (based on size, priority etc) that can be accomplised in the length of the Sprint. After this, actual time needed to accomplish the Sprint Backlog items should come from the developers. If as per developer estimation some items can not be done then some items can be pushed to the next sprint.

Like some project , as the developer gains more and more knowledge about the system they are developing theor esimation will be more and more realistic .