Recommended
More Related Content
What's hot
What's hot (20)
Similar to Hack your process
Similar to Hack your process (20)
More from damovisa
More from damovisa (7)
Recently uploaded
Recently uploaded (20)
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
- 4. The point of process Why do we do what we do?
- 5. The point of process Why do we have Scrum, or XP, or Kanban, or…? Agile > Waterfall But why adopt a different “formal” method?
- 6. Excommunication Cargo Cult
- 8. Inspect and adapt Scrum, XP, Kanban are proven ways to meet the agile goals. No limits … but …
- 9. Don’t change until you understand Consider that you might just be doing it wrong Fix the existing process instead of changing it
- 10. When to deviate And when not to
- 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
- 18. Important points Agile is about: Communication Reacting It’s a team sport - honesty and trust Measure Change for the right reasons
- 19. Protip Constant change == alarm bells To sell Anything a changing process to management, put it in $ terms.
- 20. Summary The point of process When to deviate from the path (and when not to!) Important points Questions/discussion
- 21. Your Questions?
- 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?