The joys of Agile/Scrum

[davetherave2]

So seems I have been stuck in waterfall development for far too long and over the past couple of days I have been reading up on Agile and the way that TFS can be used in it.

Although I have heard of Agile and an attempt was done a couple of years back to implement it (it did not last long due to a number of reasons) our current development team has had a number of new people in it over recent months (up to 4 developers now) that have been exposed to the agile principles

They have all come from a background of Agile so we have decided to apply the principles. I know it is going to take time to get it right but after seeing a couple of videos (although watched them in the wrong order) They are worth watching if you can:

http://blog.pluralsight.com/2013/06/17/new-course-agile-release-management/

http://www.youtube.com/watch?v=9MRbY8RqQdU

In just two and a bit hours I have understood more about the principles behind agile development than I have in the several lengthy sessions we had previously to explain the ideas to me, I see the instant benefits compared to waterfall but part of me thinks it will be difficult with having a small development team working on multiple projects at the same time.

Surely I am not alone in this situation where you can have potentially 3,4,5 or more projects on the go at once and having to carve up your time to deal with them and get them completed.

So I was wondering how others cope and deal with having to manage multiple projects using agile and what processes you have put in place to help manage it better. I work in a mainly none technical company and although we as a development team want to work in an agile way I understand that the business may find it a massive change in current working practices with us, so how do we ease them into the process without too much disruption?

Then on a separate note we have finally upgraded from SourceSafe 6.0 (I know we probably should have ditched it years ago - although we have some projects that will stay in ss6.0 for now) to TFS 2012.
I have found the learning curve a little steep (with all the extra stuff that it does other than just source control) but enjoyable and starting to understand the way of applying agile. I am finding really useful features that will help me and the rest of the development team but how easy is it to use from gaining feedback from non-technical users (Product Owners/Stake Holders) other than using the inbuilt feedback module at the end of a sprint?

One solution I am looking at currently is Telerik's TeamPulse which seems to fit the bill well in terms of giving a nice way to extend the TFS solution from a developers point of view but also allows end users to be more engaged and report back bugs, feature requests, view burn down/ velocity charts etc.
Now it is a bit pricey but I think worth the money so has anyone else used it in their development teams or are there any other products that would work just as well? Or does TFS hold its own without the need for these additional products?

Thanks in advance for any advice.

 

[davetherave2]

The best way to deal with multiple projects is by having dedicated teams with dedicated goals per-Sprint, per-Project.

Of course, the Project itself needs to have an overall iteration-based end-state, that has clearly prioritised deliverables.

With only a team of 4 developers we can be pushed from one project to the next in a moments notice. I myself have had days when I can be bounced between 4 different projects in a single day.

The nice thing at the moment is that we are having a massive review on our current application portfolio which in a way has prompted the agile discussions. We have identified that we as a team are not working in the best way and need to change and engage the business more in the process rather than producing products that are fancy and exciting because a developer has learnt something new and wants to use it rather than asking the question of "is this really suitable for the product and is it what the user wanted"

If we can get the business on board to support us in this change I can see it helping us deliver better products for them in less time. (which is ultimately what they want)

What I guess I am trying to get to is understand how we can engage the rest of the business to show them that this potentially is a better way to work for us to deliver them better products. We obviously need to give them the ability to collaborate with us in help us guide the products they want and fix any issues that come up as part of the "sprint/scrum cycles" So if we can give them simple tools that aid them and us as a development team I think the culture change will be less painful all around.

Thanks to all that have helped so far it has been very insightful.

 

[davetherave2]

Ultimately the end goal is to work better as a development team within the business and hence the thread creation.

The reason we have multiple projects on the go at the moment is because of the constant fire fighting with legacy systems, bugs, un-documented features, new client requests, "moon on a stick requests" etc. So we want to bring some order to the workload and manage the businesses expectations. If we can get them to understand that this will benefit in the long run then I see no problems with putting the emphasis on the "powers that be" to help us to help them. Two of the guys are already trialling a project in an agile (very loosely I might add) way which has provided some insight into if it will work for us and so far the stakeholders involved have been very positive (these are usually quite demanding to please as well).

I guess it is like anything when asking a group of people which way is best to go you get several different answers. It has been interesting so far to see the different views and the reasons behind them.

I guess I am looking to try and bring more order and discipline into my working practices as I have a tendency to go off-piste a lot and do my own thing/work on less important projects when I should be working on something more high priority.

 

[davetherave2]

The important thing I got from the videos and other material is that keeping everyone involved from product owner/stakeholder down to developer is part of the battle.

Yes the majority of our prpjects are very short time scale/ relatively simple so can be completed in a couple of days but I don't see why some of the principles couldn't be applied. Such as the retrosepective, daily scrum meetings, etc. The more I think about it some of our website builds are using a very loose scrum approach.

With a fundemental change to key business software within the business, scrum will be able help us manage delivery of it better.

Although not really my role (should be the dev manager) I want to try and rebuild the confidence within the business of the dev team as we have had a rough time of it over the past year or two. This is down to a number of factors that I will not bore you with, if they can see change happening for the better in the team and how it interacts with the business I see it as a win win for us if the changes are positive.

 

[davetherave2]

The development team is completely on board with moving to an agile/scrum development cycle.

I understand that there may be some projects which may not be completely suitable for this but if we can structure our bigger projects in this way then I see it as a positive move for us as a team and hopefully we can be more pro-active rather than the constant firefighting we currently do.

The more I am learning about this process the more I think "if only we had done it that way for this project it would have been delivered in half the time".

I think the main issue we have at the moment is that we as a development team are being given vague requirements and expected to come up with the solution and all the features and a lot of the time guess what the end product should be. (We develop a lot of internal applications rather than external) So if we can get a better picture of what our clients (internal and external) require then that is part of the battle.

I would rather we embrace this together both as a development team and the stakeholders of our projects to show them how much better we can work in partnership rather than some of the current running battles we have.

Once again thanks to everyone that has contributed I have a lot to think about.