One of the things of interest to me and the guys I worked with on a recent Scrum project is what happened inside a Sprint and this was brought home on the project review we conducted a few days ago; this area seems to be a hot topic not only for us but for discussion on places like the http://groups.yahoo.com/group/scrumdevelopment.
First, I think I should set a little context for this posting and to provide an insight into my opinions on this. In this article I want to clearly position Scrum, Engineering Practices (the definitive blog on this is here) and outline the approaches you have for how your team works within each Sprint – this being the missing link.
To truly understand what Scrum is you have to be clear that it is a way of improving the delivery of software and not the instructions for developing software – in fact the Certified Scrum Master (CSM) course I attended in London back in July left me slightly disappointed as Ken Schwaber and Joseph Pelrine hardly mentioned anything about what you actually do intra-sprint (remember I’m a developer!). Hopefully I can shed some light on the techniques you should use or consider adopting on a daily basis to maximise the amount of software you build and improve the quality of what you do produce.
Scrum
Scrum, well enough has been written about this so you should know what this is about by now (check out my colleague Steve Garnett’s blog dedicated to Scrum/Agile if you want to know more) however I’ve definitely formed some very clear thoughts on this,
- You either get it or you don’t – the team I worked with “got it” immediately – a consequence of us all being old timer consultants looking for something to make our life easier maybe? Who knows? But I certainly get the impression that someone either instantly warms to the opportunity Scrum offers and they seize it or they grasp an element of it but continually revert back to classic development techniques. That’s not to say a sceptic or someone who doesn’t get will never get it but they will have a longer journey to get there. They will have that “Eureka” moment eventually!
- Scrum works! Put two teams of identically skilled people/chimps into a project room, one team using a waterfall approach, the other using Scrum and the Scrum team will produce more software, more aligned with the customers requirements then the waterfall team…period!
Engineering Practices
Following on from my Agile Golf Analogy (AGA) I’d like to re-iterate one of the parallels…
“If you want to hit a golf ball further use a bigger club, do not try to hit the ball harder with the same club”
Similarly during a sprint if you want to produce more software then use better engineering practices, don’t push your team harder – it’s just not a sustainable approach. This is an absolute truth. One of the maddest discussion threads I’ve witnessed (and contributed to) on the yahoo scrumdevelopment group was one that started out asking the question “What should a BA do on a Sprint?” and ended up with two of the group’s luminaries having a slanging match over XP versus Scrum. However it did spark off some interesting discussions about the use of engineering practices within agile methodologies and one of the guys actually got pretty close to voicing my take on this.
Engineering practices are,
- Misunderstood to represent or actually be an agile methodology.
- Not limited to agile software delivery methods – they can and should be used by all development teams irrelevant of the methodology followed to deliver the software – if you are in a waterfall project you will get as much benefit as a team implementing Scrum.
- Misnamed in my opinion – they should be called “Engineering Disciplines” – as it takes discipline to use these and serious discipline to continue to use these when the pressure is on.
Process is not a dirty word
“Individuals and interactions over processes and tools” – the first tenant of the agile manifesto and a somewhat unsettling one to the PM used to a command and control environment and a possible barrier to adoption of an agile approach. "Hey Bob, get a load of this...people over processes?...no tools?...have they met our developers?....oh boy - I'm not sure about this...".
A successful Scrum project team should employ processes to deliver the software the customer wants and on time – however they are micro processes as opposed to macro processes (which can be thought of as "Anti-Processes" I guess). The tools are tactical, lightweight and easy to use and ESSENTIAL to allow the team to focus on producing software and not deploying it or documenting it or designing it to the Nth degree.
The emphasis of processes has shifted…traditionally the PM would be ensuring the team were following a strict macro process from project start to finish – what the team did during the time they were involved with their areas (design, implementation, testing) was largely ignored as long as they delivered – the lack of direction and feedback (inspect, feedback and adapt cycle) during this meant that delivery is often delayed with severe knock on consequences let alone the time between project inception and delivery increasing leading to a higher probably that the original requirements are stale. Processes are moving to the implementation team and away from the Project Managers – the team use micro processes during the day and sprint to enable Scrum to work; team member roles and responsibilities are converging.
Micro processes are found all over agile projects – however they are controlled by the people, not for controlling people. An example is the daily Scrum or how a developer approaches a task (testplan, code, test, refactor). It’s a similar case with the tools – they are adopted because they provide serious benefit in a highly specific, granular fashion – this allows best of breed adoption and is a key reason to be afraid of a single tool that claims it does it all – today it might be the bee’s knees but tomorrow it’s blown out of the water by something else. I’d use agile thinking in your approach to tools – the only certainty is change so don’t invest too heavily or lock in to a toolset and steer away from tools that prescribe heavy workflows or processes – they are introducing an overhead you just don’t need for something you could probably solve with a whiteboard.
Putting it together
So Scrum provides a method of delivering a product – it’s not the instructions for building software – in fact Ken highlighted that Scrum was being employed very successfully by architects and event planners – not a line of code, unit test or automated build script in sight! Scrum can be used to manage delivery of nearly anything and is especially suitable for the delivery of computer software.
- Scrum regularly delivers software of business value
- Keeps the team aligned with business requirements
- Allows the business to drive the project, it can be terminated early if requirements are unreasonable and unachievable WITHOUT spending a bundle of money to discover this or it can be terminated because it provides enough functionality and the remaining requirements will not provide ROI.
Engineering Disciplines provide the key to producing more software within a timeframe (sprint) whilst maintaining quality of the product. Unit tests, test driven development, continuous integration and particularly slick deployment mechanisms save time – time that is better spent on implementing features, fixing bugs or polishing the software. Another project team within our company has the build and deployment so well nailed that their testers can kick one off anytime they want with ZERO involvement from the dev team. No one has to stop work and perform this task so everyone remains focused – and that’s a good thing as task switching is cited as a major cause of inefficiency.
- Engineering Disciplines allow your team to concentrate on producing software
- A good testing framework will allow the team to make changes with confidence. Often the requirements for one sprint impact on code previously written – the team has the safety net of the unit tests to make changes with the knowledge they are not breaking anything.
- Can provide an efficient method for deploying your software – a slick build and deployment process means it can and will be used often. Software built and deployed more often allows more testing to happen, more testing will reveal more bugs which you can fix, which will make your product more robust when it ships.
- Think of these as the Airbags, Side impact bars, ABS and ESP for your project - sure its fun without them but when it matters you really wish you had them to help protect you :-)
To clarify the relationship between Scrum and Engineering Disciplines...
- Scrum is not dependent on Engineering Disciplines
- Engineering Disciplines are not dependent on Scrum
- Both can be used independently of each other however, regardless of your project delivery methodology you should be investing in Engineering Disciplines anyway.
Acid test
A great test to see if you are really Agile is imagining your customer invoking that option you sold them on – “you can stop the project after any sprint if you think we have built enough functionality to go live with”. So it happens…can you do it? Can you actually say “fine, let me burn the latest build to CD for you…et voila – your software sir”. My experience has shown that this is a very difficult thing to achieve, however the good news is that it’s Engineering Disciplines that can save the day. Granular code supported by raft of unit tests backed up by a zero effort build and deployment means rapid, quality implementation and low “time to tester” cycles.
Best practices
- Don’t just “Pair Program” – pair up on other activities like design and comment/pseudo code writing. Often another member of the team has knowledge of an area or technology you are attempting to use so leverage those skills.
- Have business domain experts (BDE) readily available and willing to pair up directly with a developer – this is almost nirvana in terms of development efficiency. Your developer becomes a translator of spoken word into computer code – as the BDE talks about a business function it appears before their very eyes! This is lean!
- Get your testers to run an informal workshop on testing – if your developers are writing unit tests then they need to be writing effective unit tests and they need to learn what this entails. Writing a single test using known “happy path” values is insufficient.
- Get everyone together in the same room. This war room will become the team’s home to do with as they please – make it productive for them, lots of whiteboards and a circular table structure promote communication – communication is the key to the removal of problems and the sharing of knowledge.
- Introduce a wiki – this allows the team to document vital project information with minimal overhead…no formatting or style guidelines – this is totally irrelevant – the information is king not the presentation. We had a single dev who did our deployments and this critical path bit us when he was on holiday. So he wiki’ed the build and deployment notes and the next build was done by someone else. They amended the notes to fill in some gaps and this process was repeated until the entire team had performed this task. The result was no critical path and the leanest documentation to do the job.
- Create an environment that facilitates fluid team bonds – one day you need to work with Joe, the next with Kate. Get that wireless network installed in the project room so team members can co-locate to work on the problem directly. If they have tablet pc’s they might even be huddled round a whiteboard taking notes that can be immediately send out or they could using a shared software whiteboard with a remote team member – don’t let £50 wireless access point become a barrier!
- Approach every sprint as if it’s your last one – this is vital in order to achieve a zero technical debt ethos should the sponsor stop the project at the end of the sprint and ask to go live with what you have.
Conclusion
Combining Engineering Disciplines with Scrum is a recipe for success. Both are simple in concept and both are difficult to do – the rewards though are astonishing so the sooner you start practicing them the better!
Update: I found this article "7 Simple Ways to Add a Little Agile without Going to Extremes" - it expands on some of the benefits outlined above to build a more compelling reason to start using them, well worth a read.