The joys of Agile/Scrum

davetherave2 · 19 Jun 2013 at 22:56

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.

Dj_Jestar · 19 Jun 2013 at 23:37

Get the fundamentals sorted before using tech tools to do it. Use index cards on a physical wall. Sketch up some frames for your workboard and then Blu-tac those mofos to a wall/board. Use columns or squares for "stages" (e.g. "Analysis", "In Progress", "Ready for showcase") or similar. Agree with the team what stages you want. You may even just have "Ready", "In Progress" and "Done" if that's what you agree upon. Time will tell if it's right or not.

The initial adoption of Agile is *hard* work. You'll be discovering much about yourselves and your workplace. There will be a lot of friction.

Remember that the one and only rule of Agile is: Be pragmatic. Don't do something just because "it's Agile". Understand what it would mean to you, your colleagues, and your business. Will it help? Will it hinder? Try it out for a few iterations and then retrospect on it if you aren't sure. Be willing to give things a go and experiment.

Regarding the multiple tasks/projects thing - it's a fallacy to multi-task. Filter and groom all of your work into one stream. Ideally everything will be in user stories (I'll let you decide what a "user story" means to your business rather than try and dictate it to you) and the stakeholders and product owner must/should decide what the priority is. If they ever say "They are equal" then just ask them "Which do you want first? Once a work stream becomes available, we must pick one but only one. Which is it to be?"

You'll quickly learn that the difficult part is convincing "the business" that it is better to delivery something than it is to nearly deliver many things. By this I mean it is better to focus on one work stream, and say "Sorry, too busy right now" to everything else until that work is done. Obviously, if something more important comes up then so be it. Stop and switch - but the point is that to be constantly doing so is detrimental.

Please, please, please also allow time for regular and frequent retrospectives. These are the most important part. You must allow for the team to look back and assess what went well and what didn't. Try and use a structured plan of "Retrospective games" to avoid letting the discussion get bogged down in a bitchfest.

Good luck.

P.S. there are plenty of discussion groups and various meetups in all the major cities if you want to meet other agilists and discover what is going on at other companies.

NathanE · 20 Jun 2013 at 08:39

Agile is 90% about the way you write code, test it and your release cycle. 10% of it is having and maintaining a Kanban board along with other "business process" stuff.

Of course, the "suits" will tell you the ratio is the other way around.

Random Guy · 20 Jun 2013 at 08:56

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.

topbanana · 20 Jun 2013 at 09:15

It sounds like Kanban might be better suited to you than Scrum

DanF · 20 Jun 2013 at 10:10

Check out trello as well, it's a very simple but flexible board/tracker system which is very easy to prototype in. You can get it right here and if you still want to use TFS afterwards

then implement it there.

davetherave2 · 20 Jun 2013 at 10:17

Random Guy said:
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.

Muel · 20 Jun 2013 at 12:41

topbanana said:
It sounds like Kanban might be better suited to you than Scrum

Seconded. I work in Scrum but built a Kanban based system for my dissertation, definitely sounds like Scrum would be too much, too soon IMO.

Random Guy · 20 Jun 2013 at 13:31

4 Devs to take on an Application Porfolio for Agile...well the good thing is that because the team is so small, you can build and refine your processes, and most importantly *manage* them well.

At it's heart, Agile is a simple concept. Don't assume there is a "right" way to do it, but there is definitely a myriad "wrong" number of ways to do it. I think the best thing about it, is that it is almost completely feature-based and iteration-focused. If you can determine the "good-flight", best-path, must-have functionality for your portfolio, then you can still try and prioritise using the methods others have mentioned, per-application (maybe each Application has its own Backlog).

D.P. · 20 Jun 2013 at 16:01

Muel said:
Seconded. I work in Scrum but built a Kanban based system for my dissertation, definitely sounds like Scrum would be too much, too soon IMO.

Not that I am that experienced but a Kanban systems seems appreciate here. I work in a team of 4 engineers working on multiple different tasks I gloving large complex software and we roughly follow a Kanban Approach but without any formalism. Works quite well in dynamic environments where you do a lot of firefighting (resolving biggest crisis or defiiciency first). Very iterative and evolutionary development but no defined cycles

Dj_Jestar · 20 Jun 2013 at 18:28

KanBan requires way more discipline than Scrum. In the sense it takes a lot more self and team discipline to stop everything from falling apart. I don't want to be derisive to Scrum, but it's training wheels stuff. Everything is spelled out for you in the book(s).

The usual progression is to employ Scrum to get people used to the iterative approach, then mature into a KanBan-like pull system/model of your own design.

I don't think anything will be gained by jumping into KanBan (read: trying to engineer your own model) head first without having a structured model like Scrum to get you learning the principles first.

topbanana · 20 Jun 2013 at 19:37

Dj_Jestar said:
I don't think anything will be gained by jumping into KanBan

Have you ever used Kanban? It's simpler than Scrum. Besides, Scrum will be no good at all here because he has 3, 4 or 5 projects on the go at once.

Dj_Jestar · 20 Jun 2013 at 22:04

Yes. I've used and mentored it for nearly 7 years

Scrum can work with any number of projects as long as the work stream is prioritised and singular. Scrum of scrums and all that.

KanBan is only simpler than Scrum on the face of it. It is actually the simplicity and flexibility that makes it so much more demanding.

davetherave2 · 21 Jun 2013 at 00:01

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.

D.P. · 21 Jun 2013 at 03:32

Double post

D.P. · 21 Jun 2013 at 03:34

davetherave2 said:
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.

Your environment sounds much like hours, small team constantly working on new problems under tight deadlines- very dynamic and unpredictable. In these cases I just don't see any formalized system like Agile working at all. Our co,pay paid a guru consultant to spend a week with us and report on best management styles and development processes. Formal systems like Agile were dismissed because in such small teams with volatile and dynamic workloads.

If in a single day the team may work on 3-4 different projects then even short iterative cycles make little sense. It is all well and good planning your 6 week push when on the 3rd day you get word from the CEO that a VC wants to see feature X by Friday or they will withdraw negotions then you drop everything like a hot rock and work to 3am on the magic money making feature.

You really have to take iteration to the extreme. Consider what features/big fixes you could achieve in the next few days and see if that would fit in with the latest firefighting. About the only Agile thing we do is we have a daily morning scrum to share news, report on progress/bugs/issues and reinforce the team and cooperation. Really a lot of it comes down to how good the developers are at managing their time, cooperating and not loosing their mind. Most of out team have PhD so are very experienced in time management and maintaining focus, rapidly resolving issues, cooperating, etc.

One other handy thing is to regularly go out for beers together, relax, discuss work issues with the manager and CEO, then have fun!

Dj_Jestar · 21 Jun 2013 at 10:08

D.P. said:
formalized system like Agile

Does not compute.

The very premise of Agile is rapid change and adaptation, pragmatism and not having a formal process! Coz ya know, agility.

D.P. · 21 Jun 2013 at 15:33

Dj_Jestar said:
Does not compute.

The very premise of Agile is rapid change and adaptation, pragmatism and not having a formal process! Coz ya know, agility.

Well that's is the thing, Agile is just very hypocritical because it is a formal process, otherwise it wouldn't even have a name let alone a whole manifesto and doctrine. Agile is really a load of flashy words and marketing mumbo to describe how software was developed in the 50s and 60s which people have recently found to be useful again. Shock horror, project manage,net practices designed around hardware in large factories with fixed environments and rigid requirements don't work well for software

Dj_Jestar · 21 Jun 2013 at 17:32

Please demonstrate the formality in Agile.

topbanana · 21 Jun 2013 at 20:46

DP, Agile isn't a process at all, formal or otherwise. I have a name, and I'm not a process.