A successful process is not one size fits all; every team and project is different. Scrum may be an awesome framework for managing your development process, but it should only be a starting point.
In this session, we’ll look at when and how to inspect and adapt your own process to increase the effectiveness of your team. We’ll look at examples of projects that have deviated from the norm, the reasons for change, and why they succeeded or failed. Finally, we’ll look at how you can apply these learnings to your own team process.
Learn how to excommunicate yourself from the cargo-cult and starting making your process work for you.
Workshop - Best of Both Worlds_ Combine KG and Vector search for enhanced R...
Hack your process
1. ASP.NET Web Forms
ASP.NET MVC
Hack Your Process
Excommunicate yourself from the cargo cult
Presented by Damian Brady (@damovisa) – Solution Architect @ SSW
Twitter Live Backchannel: #SSWDev
Delivering Awesome Web Applications
2. Damian Brady – SA @ SSW
w: damianbrady.com.au | e: DamianBrady@ssw.com.au | t: @damovisa
Software Architecture
Scrum
Team Foundation Server
Mobile Web Applications
Technology aficionado
TFS
ASP.NET + MVC
HTML5 + CSS + JS
Web Forms
Windows Forms
3. Agenda
The point of process
When to deviate from the path (and
when not to!)
Important points
Questions/discussion
11. When to deviate
What are you losing? Has it been replaced?
Three common examples:
Organisational restrictions beyond your control
Unpredictable work
Non-standard projects
12. Organisational restrictions
e.g. Upfront fixed-price
fixed-schedule is a must
External vs Internal process
Dev Lead / Project
Manager: Protect your
team!
Tracking extra data
13. Unpredictable work
e.g. Support and Dev
team are the same
You can’t track what you
don’t record!
14. Non-standard projects
E.g. R&D Projects
You can often fit these into
Scrum
Timeboxed spiking tasks
Reduced availability
What are your goals?
15. Spiking is not just for software
Spike your process
Be prepared to change
back
“Responding to change”
16. When NOT to deviate
Because it’s annoying
Don’t be hamstrung by your software
Ditch the tool before ditching the process
22. Other resources
How to implement Scrum using TFS 2012 – Gerard
Beckerleg
Agile Anti-Patterns – Sander Hoogendoorn
SSW Scrum Consulting
23. Ping me maybe?
DamianBrady@ssw.com.au
http://damianbrady.com.au/
twitter.com/damovisa
24. Thank You!
Sydney | Melbourne | Brisbane | Adelaide
info@ssw.com.au
www.ssw.com.au
Delivering Awesome Web Applications
Editor's Notes
Why is agile better than waterfall?The answer seems obvious – you can react to change, you’re not locked in by bad requirements or bad spec, you can change direction, etc. It avoids the go-away-and-develop-for-months-and-come-back-with-the-wrong-software problem.Often people get convinced to try Scrum but they don’t really know or care what it should actually do for them…
Everyone knows the cargo cult story (right?)Short version is soldiers used an island as a base in a war and the islanders saw that when they spoke into their radios, they’d get airdrops of food. Fast forward to when soldiers were gone and the islanders started building these wood and coconut radios trying to get this food to fall from the sky. Moral is: just following a process without understanding it is no guarantee of success.Scrum and other agile methods have often been used like cargo cults. Blindly following scrum because you have the same problems it’s supposed to solve is kind of like buying infomercial products. “I’ve got that problem! Shut up and take my money!”
The agile manifesto was thought up by a bunch of guys who all used different techniques for managing their projects – it’s the consolidation of what they realised was important for better software development.There are some threads in here – check out these words – they’re all about communication. Communication is key to all this. Talk to each other, and talk to the customer.Responding to change gets its own item – a quarter of the manifesto. This is the inspection and adaption part of agile, and it’s one reason agile development is so successful.Remember, this is the “agile” manifesto, not the Scrum manifesto or the Kanban manifesto or the XP manifesto. The actual method you use to achieve these goals doesn’t matter – it’s the goals that matter.[after skip]Scrum has predetermined meetings to make sure you interact with other individualsYou have Definitions of Done to make sure you get working softwareYou loosely define stories, have an accessible Product Owner, and go through sprint reviews to make sure there is customer collaborationYou plan work in short sprints to make sure you are Responding to change
Scrum, XP, and Kanban have rules you have to follow to ensure you meet those goals:[skip back]These things are importantSo what can you change as part of this inspection and adaption of your process?
Don’t change until you understand!Expert suggestions are there for a reason – 2 or 3 week sprints, retro, planning, 10min standupsConsider you might be doing it wrong:Better to focus your attention on trying to fix the problem within the existing framework than to just start changing things – standups boring and useless? Refocus – don’t change the frequency or start timeCake recipe – I wouldn’t replace an ingredient with another one because I don’t have enough experience. Same goes with Scrum. Don’t decide to change the meetings or frequency or sprint length until you understand why you’ve been told to do it that way
First step is truly understanding what you’ll lose if you change something and making sure you’re covering for it.Make sure you understandin depth – e.g. Standups – Why daily? Why standing? Why everyone?
Plenty of examples of this – it’s the most common variation I see (and I’ve seen it done very successfully)Fixed price means estimates and long-term commitments – this doesn’t fit nicely with Scrum. Velocity becomes extremely important here for estimating.The secret is that you can separate your internal process and your external process. Use standard delivery dates and milestones externally, but work within Scrum internally.Some things can’t change though – you still need to be able to talk to the Product Owner.If you have a large project with a separate BA team, you might be able to make one of your BAs the “Product Owner” if direct client contact isn’t an option, but know that you’re compromising the project.If you’re a dev lead or PM… The number 1 rule is “Protect your team” (shit umbrella). There will be arguments, changing requirements, hard deadlines, etc. Your most important job is to make things smooth for the team – if they’re using Scrum, don’t leak through that abstraction – let them do Scrum and translate what comes to you in Scrum terms.Additionally, there’s often a need in larger organisations to track data that Scrum doesn’t tend to track. E.g. how long a task took vs how long the estimate was (really common). If you need to track this, then track it. The TFS template for MSF Agile has this value for the Task WIT, but the Scrum template doesn’t.
Again, this is really common and can lead to very unpredictable availability.The best solution is (obviously) to fix the underlying problem – take your team member off support, but it’s not always possible.e.g. A company I worked for where there was one guy on support as well as on our project teamWe tried assigning specific days for support (reducing his availability), but that didn’t work because the support was unpredictable. Ultimately we put a line under the backlog and called them stretch tasks. Based on the amount of time spent on support that sprint, they *might* be done. We planned both ways. Most of all, we tracked how much time he spent.Hard to plan or get a stable velocity – you must track!Scrum focuses on remaining time (for the burndown) rather than time taken, but… if you keep notes on how much time you spend on support tasks – in a PBI or in some kind of external register – it will help your predictionsThe danger with not tracking support (and just letting it affect velocity) is you now have several variables. Is the reduction in velocity because of increased support or another cause?Adam: User Story called “Noise” to track additional tasks that come in. Put it up, move something down.
Unclear requirements – just a long series of spikes and investigation tasksYou can often fit these into Scrum with timeboxed backlog items, short sprints, etc. Explain Spike!You could also grant each team member x days to do research tasks per sprint and just take that off their availabilityUltimately, plan your process around what your goals are.In a lot of cases, Scrum is still a great option. Is your goal to see if certain techniques will work? Use timeboxed spiking tasks. Is your goal to spend x hours investigating new stuff (e.g. 20% times)? Then just take that off your availabilityJoel Pobar’s project – 1-3 day spiking tasks aiming for 1-3% performance increases. Scrum *may* have worked, but it wouldn’t have been an ideal fit.
If you have an idea for how to improve your process – try it, but be prepared to abandon itSome of the best projects I’ve been on changed something nearly every sprint. Many things didn’t work, but a lot did and really helped.Change your sprint length? Standup in a different place? Track a new metric? Split the team in half? If you think it’ll help, try it!
Do *not* change your process because you can’t be bothered. Scrum (and process in general) is hard to master. Ken Schwaber and Jeff Sutherland admit it in about paragraph 3 of the Scrum Guide.Doing this is just a lack of professionalism along the same lines as disabling tests because they fail or patching directly to production because you can’t be bothered pushing the change through your environments.TFS is highly customizable – I just spent a week introducing a new WIT for a company so Scrum would fit with their KPIs – it allowed them to track all the things they needed to track, and enforced their process (only certain team members could do certain things)One of the most successful Scrum projects I’ve worked on used a board with post-its for planning rather than TFS. One guy was responsible for syncing the PBIs in TFS after each standup so we could get a burndown. It let the devs concentrate on working with code rather than work items. (Now, of course, that process is much, much easier in TFS 2012 with the My Work page)
RE Honesty: Sometimes the problem is people. (e.g. Bill, Joe) - you may have to go to extremes (e.g. take someone off the team)
What pain points do you have in your process?How do you think we can fix them?
