Recently I joined the DotNetNuke Engineering team, specifically as the Director of Engineering where my primary focus will be on NEW development; that would include both new features, and enhancements to existing features and enhancements at the core level. What this means is that my team and I will be responsible for soliciting feedback from our various customers and producing feature/functional design specifications, transitioning those to technical requirements and eventually pushing those features into a future release of the product.

Side Note: Joe Brinkman will be taking on Support and Maintenance of the product moving forward. There will be a natural flow of information and events from my team into his team.

In the interest of being transparent with the community I want to open the door to the community and allow us to discuss these items openly. First and foremost I wanted to give a quick background on the development methodology and the high-level points which we my team be adopting.

Second I will cover the current progress made to date so far, within that methodology.

And finally I wanted to cover off things what YOU can do, as a community to help grow the product.

Development Methodology

Scrum

The plan, which is in its early adoption phase, is to follow the Scrum methodology. We are now just taking our first baby steps into our first official sprint within the organization.

Shaun Walker, Joe Brinkman, Charles Nurse and I have gathered to examine the complete list of items on our Product Backlog – which Shaun currently maintains, and have decided on this feature set to be delivered in the next sprint.

I recently gave a presentation to my team, and here are the high level points which the team needs to understand:

1. This process is currently limited to the Engineering / Development team

a. This, for now, excludes the product support and maintenance team

2. We hold a daily scrum at 10:00am

3. If you cannot attend physically you are required to call in (we have a VOIP based conference room setup)

4. We enforce strict penalties for tardiness ($1.00 into our beer fund, or 10 pushups)

5. The newest hire is responsible for:

a. Taking Scrum notes

b. Updating the Burn down chart

6. The ScrumMaster, for now, is me

7. The person who currently represents the Key Stakeholders is Shaun

Schedule

Some of the key dates to take note of include:

1. Scum meetings happen at 10:00am, all to attend

2. We have month long iterations, which follow the general guidelines of:

a. Day 1: Sprint Planning Meeting

b. Day 2: Task breakdown, accept work (duration is tentative)

c. Day 3 to Day 21: Development effort

d. Day 22: QA Hand off

e. Day 22 to Day 30 : QA Effort – end result is a potentially shippable product

3. Quarterly Feature Releases (Maintenance releases are monthly)

It is important to note that although we have monthly sprints, we only release quarterly. This means we are going to try to make available these interim feature builds to the community. The exact nature and plan for this is still tentative. This also allows for the sales cycle to pick and choose their build for demo’s and trade shows – fully tested and stable vs. latest and greatest feature set.

As a side note, we have officially adopted Olympic City names for our development sprint names. For the first sprint, which has already start has a code name of Vancouver. The next sprint will be named Sydney.

Our timeline of events, at a very high level is as follows:

1. 5.3 - Vancouver Sprint is due

2. 5.3 - Vancouver Beta Customer Release

3. 5.3 - Sydney Sprint is due

4. 5.3 – General public release

Planning/Tasking

In the past I have had much success in implementing the usage of Sticky notes for project tasking and tracking. What this means is that as we gather to break down each major feature set down into its various bits we keep track of each task with the help of sticky notes. On each note, we indicate the Sprint (5.3/Vancouver, etc). Which component which is being worked on, the task name (Create table to store xyz) and the approximate “size” of the task (1-4). If the task is larger than a 4, we simply break it down even further.

The goal of this is, is to get a broad picture and “size” of each deliverable and how much the team can deliver in a fixed amount of time. For example if we add up the size of all of the tasks, across the team, and it adds up to 100 and we deliver that early, then we know that next time we should consider adding more items to the Sprint Backlog (work to be delivered). If we can’t meet the deadline then we have over allocated and will need to adjust accordingly. Over time what happens is, as the team matures, the amount which we need to adjust for each sprint is reduced and we have a very predictable method for estimating how much work to take on during each Sprint.

Now that we have each of our tasks broken down and on stickies we have a large board in the office which we place of them on, under one of the following columns/categories:

1. Backlog

2. In Progress (and each person has an In-Progress column)

3. Deferred

4. QA

As each developer begins a task, and moves it along to completion they are to also move the sticky. This gives everyone a very obvious indicator of progress. Take for example the QA team; they know what features are coming in the near future and when. Shaun can take a look at the board and see the progress being made by the team.

It is very important for me to have this exist in the physical world. It needs to be out there, just like our dirty laundry. It keeps us in check and on the ball, not to mention being extremely transparent with the rest of the team.

What can you do?

If you do not already have a channel into DotNeNuke and you want to get involved drop me an email. If I can’t handle your request directly I will do my best to put you into contact with the correct person on our team! Feature requests, glaring issues that are just killing your adoption, comments/feedback on our process and methodology, or if you just want to pick my brain feel free to get in touch with me.

No Comments