Agile – bringing it back on track

So in my last post I outlined the situation I encountered when I joined my new company, now here’s what happened at the end of the first full sprint.

The scrum master worked with the product owners to groom their backlogs which then came to the team to story point to allow us start calculating velocity for future planning.

The scrum master was out of the office so I stepped in and ran the review, retrospective and sprint planning.

In the review we had no product owners turn up so to set expectations I got the members of the team that had worked on various projects/products to demo them to the rest of the team, this served 2 purposes:

1. Team gets used to demoing the work that they’ve completed
2. Share knowledge within the team

The review went well with the team asking questions about the various projects to get a better understanding of what the different team members had been working on – its not full understanding of the code but it better than nothing plus good to see the team wanting to share the knowledge.

We then moved onto the retrospective and I got the team to do Start, Stop, Continue to identify what they’d like to change in the process, after we went round the table getting feedback from the team we all voted on the things to focus on.

After the retrospective we did the planning, now this was the first time in a long time that the team worked out the number of hours they’d have to work during the sprint (based on 6 hours a day and 9 days in the sprint, last day given over to the sprint meetings) then tasking time ‘off the top’ for meetings, training, etc.  Once we had the actual amount of hours to work with we got the stories newly groomed by the scrum master and tasked them out, and we continued until we reached about 80% of the available hours and then decided as a team to commit to the work.  We tasked out some additional stories in case the team got through work quicker than expected just to have tasked stories in hand to simply pull in and work on.

Doing this was a different way of working and some members of the team were a little uncertain as to why we were doing this and what we would gain, what was nice was the members of the team that did understand explained it to the others rather than me telling them and coming across as ‘dictating’ to them.

During the next sprint we worked through the stories on the board, the scrum master protected the team so the pink stickies on the board were reduced (unplanned work) and the product owners attended the daily scrums.  We got hit with a massive support problem but had taken a substantial number of hours off the top to handle this so we didn’t have to drop any stories out.

At the end of the sprint we had succeeded.  All committed work completed, tested and ready to be deployed (we have to get approval for system deployment by a global change board, otherwise would have deployed in the sprint) and we had managed to handle the support, including a massive problem what we got hit with.

It seemed that my actions were helping but that was just one sprint, the next sprints will decide if any lasting change has been made.

Next post will go into the next set of sprint meetings and what happened in the next sprint.

When agile goes bad

Now I’ve not posted much about agile/Scrum/lean even though I helped introduce Scrum to my previous employer.

When I first started at my new job when I arrived and I saw the board I knew something had gone very wrong.  There was no sign of any stories, the ‘cards’ on the board represented tasks, there was no visible definition of done, I could go on.

I had joined mid sprint so instead of trying to make any changes immediately I observed what was going on for the rest of the sprint.  The daily standup was taking place with people being told by the scrum master to answer the 3 questions but very quickly people started launching into discussions, the sprint review had no demo to any product owners or even the team and the retrospective seemed to simply have people list what they thought went well and what went badly with no actions to change anything.

Although the team thought that they were ‘doing agile’ it seemed very much that they were simply reacting to work that was being thrown at them and this included during the sprint.

The poor scrum master was pulling his hair out trying to protect the team from interruptions and work just being dropped on them but management frequently by passed him.

To try and help the first thing I did was to work with the scrum master to take everything back to basics.  We got stories defined for the next sprint, at sprint planning we worked out the hours that could be committed to and then decomposed the stories into tasks until we reached the umber of hours that the team felt they could commit to.

During the sprint some more work got thrown in but we used a luminous pink sticky to show all unplanned work to help give managers a simple visual indication of what was happening.  We also got hit with a massive support problem but because it ate into our hours the team along with the scrum master determined what stories should be dropped out to compensate.

At the end of the sprint the team hadn’t completed all the work but we had a better understanding of why and what we may be able to do about this.  In the review the work was demo’d and in the retrospective I did Start/Stop/Continue with actions to try to remove some of the problems.

I’ll cover what happened in another post.

Asp.Net Dynamic Data – should you use it?

I’ve wanted to write this post for a while but have held off until I had completed my posts on dynamic data (DD) display and validation attributes and my thoughts on Linq-to-Sql.

Disclaimer: this post is all about DD on .Net 3.5 not .Net 4.0, I’ve not had a chance to play with the .Net 4 version yet.

Now DD provides an excellent way to build CRUD applications against a database, in a matter of moments you can have a functioning application and as its Asp.Net you can easily customise the application to add security, change its appearance, etc and through its Meta data driven buddy classes it becomes easy to alter what DD renders.

However, it is when you want to extend a DD application to do more than its simple CRUD operations you start to run into its limitations.  If using Linq-to-sql, without extending the entities, then you are effectively forced to work in a Transaction Script style which is fine for simple applications but very quickly you start to struggle as the complexity rises, plus, it is almost impossible to do TDD with DD & Linq-to-sql combination.

If you extend the entities in Linq-to-sql or use Entity Framework then you can start to work in an Active Record style but due to the intertwined nature of the logic and the data its still almost impossible to do TDD (an interesting aside is this post I found which mentions ‘the Active Record Anti-Pattern’ which is the first time I’ve heard of one of the main architectural patterns described as an ‘anti-pattern').  By extending the entities you do gain the ability to add logic to them making some tasks easier but as the complexity continues to rise you again run into problems trying to make what should be easy work for you.

An example: In my last job the final piece of work that the team worked on we decided to use DD as it provided us the opportunity to get the site working in a short period of time.  Now everything started fine we got the site working quickly, styled it appropriately and it all looked good, then the changes began. With each change the logic that was required increased in complexity and if we hadn’t been using DD we could have had a nice suite of tests to help us test the logic but we didn’t, so we could only perform functional testing which meant that the boundary and corner cases were difficult to test and mistakes were made. 

What I and my previous team learnt from this is that when using DD there is a tipping point you reach where the functionality DD provides is outweighed by the complexity of extending it.

So should you use Dynamic Data? As with most things it depends – if you only need CRUD actions like a simple data entry application then its perfect, but if you know that you’ll need to extend or implement complex logic I would suggest that you use standard Asp.Net web forms or MVC as it will ultimately be quicker and easier for you to develop and test.

I’d love to hear from anybody who has experience from using DD and how they got on.

CodeProject