Tag Archives: Scrum

Maintenance within a Single Scrum Team

During the past month, a relatively new form of resource management has taken afoot at within our team.

Two separate factors contributed to this shift of developer resources:

1. Budget Constraints

2. Compliance Requirements

The first, budget, came from the management’s decision not to extend most of consultancy contracts – all of which were already overdrawn, for a specific product. With new product offering in the company portfolio for next year, the in-house developer resources have been tapped to finish Release-1.

The second, compliance, was a legal overhead to comply with certain Sarbanes-Oxley requirements, so we can have proof of our security practices, effectively in place.

For now, it should suffice to mention that BOTH of such factors are what I’ve come to experience at most companies where software is now an integral part of portfolio – or suite of products – so that it has a direct effect on the bottom-line.

Given these concerns, our team decided to deal with developer scarcity by splitting the single team into two schedules, a morning-section (9 – 12) of maintenance and Scrum stand-ups and the after-lunch section (2 – 6) of new development. We effectively time-boxed ‘maimtenance’ into the mornings.

Judging from the past month, the time-box worked rather well, increasing focus on a single WIP for either task buckets – new dev and maintenance.

However, it also left an unsatisfactory thirst in my appetite for completing a task. While neither task bucket was unattended for very long, this required us to shift our focus from-and-to the two buckets every single day.

The only happy campers are the staffers wanting more maintenance tasks finished off. What cannot be determined currently is whether the new offering portfolio can be fully supported.

The point of running a Scrum Team has been skewed, by non-technical factors. I wonder whether our past year should now be considered a failure in resource management, or a bigger-scoped project management.

Advertisements

Scrum and Kanban

Weeks ago, our team had our first workshop in Agile-Scrum. Our CSM gave an overview of the approach and some of the basic reasons behind it.

Key take-aways:

1. Focused/Vertical dev effort.
2. Flexibility as a built-in application of the method
3. Learn as we do, to lead to doing it better

We also decided to bring in TDD and BDD into the mix, using TDD first, with the goal of using BDD with a future project.

Test-driven development using nUnit, TestDriven.net plugin for VS2010. Behavior-driven development using SpecFlow.

Continuous Integration will soon be in the process, most likely using TeamCity to manage our builds, from SubVersion repository.

Our key concern is the divergence of efforts, as we decided to keep devoting 25% of the team to maintenance efforts of legacy apps, using Kanban approach.

Hoping to increase team productivity, 75% of the team (not on maintrnance track) will be focused on a single item of WIP (work in progress), at any given time. Each sprint is one week long.

Frequent interaction and feedback with product owner is key. Self organization within the team, using pomodoro and time-boxing methods, will be useful.

On the table for client-side testing is employing qUnit to properly test JavaScript/jQuery interactions with the DOM and web services.

Planning to add additional memoir on Scrum/Kanban in the coming months.