Scrum and government – has dating gone to far this time?
In my work I am on a never ending crusade for finding other public sector or government organisations that are at least trying to use Scrum in their daily work. Alot of issues usually stands in the way for these organisations in order to be able to commit to Scrum 100% – and thats why many of these organisations are in fact doing scrumbutt and not Scrum. The typical response for NOT doing Scrum in these organisations is – and the order is TOTALLY randomized!!!:
1. Due to contract constraints we need a fixed budget / price from the vendor
2. Due to budget constraints we need a requirement specification before starting the project
3. Due to the assumed lack of documentation and reporting mecanisme in agile projects we can not allow this
4. Due to the surrounding stakeholders and/or organisation using [pick one] waterfall method there is unfortunately no way an agile project will fit into our world view
5. Due to too many out-of-project-tasks (ad hoc) we can not see what lies ahead of us and therefore unable to really do a timeboxed planning method (sprints/iterations etc.)
6. Due to my boss / board of directors / managers [pick one] lack of interest or will to let go of the stronghold of the projects, I can not see how all this agile fits into my world
7. Due to… well the list could go on forever, but I think you can see the overall picture here…
- much of this is about lack of trust in the method, the teams, the colleagues and many other things.
So before I get to answer the bullets above, I want to share some valuable information – because IF you are in one these situations, then you are not alone – and there is in fact people out there, who has alot of knowledge that can help, and they are more than willing to give tip and tricks!
So here is a recap or shortlist of public sector organisations, who in some way are using an agile approach on their projects – their level of experience are very different, but they all got something they wanted to share with me, when I turned to them -
North America:
Danube – http://www.danube.com/ Company that tried starting up a yahoo workgroup around Scrum in governments 1½ year ago… Got clients in US and Canada that are based with Scrum and in the public sector.
Idaho Dept. of Health & Welfare- US – is doing mission critical software development through Scrum – been replacing old mainframes and other projects
Quality Counsil of Alberta, Edmonton – Canada – This counsil sole purpose is to share knowledge on lean, agile, six sigma and many other cool theories. It is an public sector organisation and funded through the Edmonton region.
Code71 – small midsize company that are running Scrum projects together with government vendors – creators of www.scrumpad.com
PMI.org – probably the world largest project organisation – Own project certification and are working together with Scrum Alliance now for an agile approach of their education and training.
Scrum Alliance – setting up user groups and ScrumHubs for knowledge sharing – so check out their website for these!
South America
PMI.org – again -has extensive work in Brazil wokring together with many public sector organisations
UNICAMP – State University is looking into using Scrum together with Teamware from Brazil
Europe:
Softhouse AG – Sweden based consulting and development company – in Sweden they are known for their development, but outside Sweden they are known for their skilled trainers and consultants – they are in charge of the Öresund Agile confernce. Look out for their blogging here on agilethis.com
TriFork – Denmark is a company filled with skilled consultants that has been working with Scrum for years. They have a large development department and they are in charge of the annual JAOO conference.
CRISP AG – Sweden – evangelists and trainers within Scrum, Lean and agile – top of the notch – simple as that! – you can follow their work here on agilethis.com
The Danish National IT and Telefom Agency – Denmark – my work – evangelists of Scrum and agile approach – we are using Scrum for external projects and agile methods internally – its been a long road and we have only just scratch the paint. Doing work on legal guidelines for agile contracts right now. We are aiming at using Scrum within PRINCE2 and it is working!
The Danish Agency for Governmental Management – Denmark – on of our sister agencies that are looking towards Scrum now – we have alot of work together and alot of mindsharing on agile methods.
Asia/Australia:
Dept of Environment and Resource Management, Australia – Has been doing Scrum for nearly 2½ years now – they won awards in Australia for the groundbreaking work they have have done with Scrum. If you are looking for PRINCE2 and Scrum this is it!
Software with Style – Canberra, Australia – doing Scrum together with public sector vendors – trainer and evangelist
So this is just the short version – there are more out there – if you need the contactinfo for any of the above let me know!
So back to my bullets – by now many of you must be eager to hear, what I have to say about the different subjects…
1. Due to contract constraints we need a fixed budget / price from the vendor
This overall perception is all about time, money and quality – we have to move our scope from just selecting the cheapest vendor for a project to working with a project budget frame. Set a budget for the project, and pick the vendor that you feel can deliver the highest quality/value. Time should not be focused on initially but should be addressed before starting the project – it is ok to have a deadline – also in the agile world! If you have a hard time selecting a vendor do a proof-of-concept or a sprint ZERO – that way you AND the vendor can see what you gain from this project… it might be that the vendor doesnt want to work with you!
2. Due to budget constraints we need a requirement specification before starting the project
Requirements change – all the time – and if you pick all your requirement in the beginning of the project you lock yourself down on these – and that is a shame! By doing this the cost for changing the requirements will go up – and it will be more and more expensive to change them as the project evolves.
Start up with a vision (guiding star) for the project – perhaps a few small userstories as requirements – but dont do 1500 pages – most of it will be vaste and have to be reviewed again and again. Find out how much work with the userstories is needed for you to actually start the project – and then start! So build a small backlog to start up with – you never know if your vendor has knowledge of smart or more innovative solutions than yourself!
3. Due to the assumed lack of documentation and reporting mecanisme in agile projects we can not allow this
Scrum doesnt say you shouldnt do documentation – you should indeed! Scrum is a tool for improving communication – COMMUNICATION!!! …is about coming together and sorting out issues that surrounds the project. Text doesnt bring value – but if someone reads it out load it will – a conference call brings some value – a standup meeting brings alot of value. Let me just bring this perfect image from Alistair Cockburn – thanks to Tom Kealey for bringing that up:
…and remember just because you have standups, you should still do proper documentation of your work – so set a working agreement for your project and team before you start!
4. Due to the surrounding stakeholders and/or organisation using [pick one] waterfall method there is unfortunately no way an agile project will fit into our world view
You know… I really cant recall seeing a single project method where the execution of the project itself or “the engine” couldnt be replaced – in some methods the engine is actually missing – And given the fact that in many methods we are actually talking about the same things, numbers, report – just on different levels!
An example:
PRINCE2 is having their own hiraki of their projects – corporate portfolio -> program(s) -> project(s) -> activities -> tasks
Scrum is working with the 3 last layers – project -> activities -> tasks as in project -> epic -> theme -> userstories -> tasks
So I were to merge the two – since Scrum in my oppinion has a better engine for execution of the project – I would go for this model:
Portfolio -> Program(s) -> Project (s) -> epic -> theme -> userstories -> tasks
PRINCE2 is in this case simply not delivering us anything, and we can find perhaps even better mechanism in other methods. Again – it is important for people to realize that Scrum is designed with the sole purpose of delivering the most value to the customer, when the project is running – and Scrum is not set for delivering tools for managing your budgets or portfolio. If I – personally – had a portfolio and budget for – lets say – 100mio US$ – even I would need a controlling mechanism to control that. I wouldn’t wanna just let go and hope for the best.
I remember that Martin Kearns from Renewtek asked the exact same question to Mike Cohn from Mountaingoatsoftware on the last gathering in Orlando – and his answer was the same: If you have a large portfolio and budget – you need Scrum to work in a controlled environment!
5. Due to too many out-of-project-tasks (ad hoc) we can not see what lies ahead of us and therefore unable to really do a timeboxed planning method (sprints/iterations etc.)
These tasks are always something that can kill a project if there is enough of them – and thats why we need documentation and tracking of our work – hence the burndown. I will write another post on burndowns themself at a later stage.
The burndown is there for us to keep track of our progress, our capacity – our velocity. When tasks suddenly comes flying in, it will immediately show on the charts that the team isnt burning down on the backlog. So what can you do – well first thing is to identify, where the tasks are coming from – most ad hoc tasks is a product from others lack of planning – remember that if the surroundings are used to you taking everything into your backlog as they come, they will have a hard time dealing with you being on a project.
Another thing is to set your capacity lower than what it really is for the project – plan with 60-80% of your capacity for your project and the rest for your incoming ad hoc tasks. This will make it alot more easy to plan with, and in the end you will be able to satisfy both your customer and your surroundings alot more.
6. Due to my boss / board of directors / managers [pick one] lack of interest or will to let go of the stronghold of the projects, I can not see how all this agile fits into my world
It is not easy to implement Scrum in a controlled environment – it takes alot of time and hard work. Many of the situations I meet out there is regarding management feeling they are losing control, but it really doesnt need to be like that.
In Scrum we have alot of other reporting tools that in the end delivers a continuous and often improved feedback to the management. You need to find out what the management wants and then FEED THE NEED! If it is a monthly status report – write it – if it is a pie in excel showing the sprint/product progress – do it. Usually it is very little that stands in the way of going agile and the management – so go to your manager and ask what he or she wants and then set some common workrules for it – you need the manager there as well for showing commitment to the project in front of the team, right?
So the recap of all this is that there is in fact many public sector and government organisations that are running Scrum or other agile approaches – many of them have tried thousands of adjustments and can tell you what worked for them and why – we are not alone!!!
I hope you enjoyed reading!
/Chris.
----------------------------Christian Vindinge Rasmussen




Thank you,– this is FANTASTIC resource! I look forward to reading these items and contributing back in return around Agile contracting and agreements!
The one thing you do not mention in you article is the legal framework applying for the public sector regulating public procurement. (http://ec.europa.eu/environment/gpp/legal_framework_en.htm). This is the biggest obstactle for implementing scrum in the public sector.
In your article you mention things like “pick the vendor that you feel”. In the public sector, at least within the EU, you cannot pick the one you “feel” is right for the project. The main rule in this legal framework is that you are not even allowed to speak to any of the vendors before the contract is signed (b/c everybody is to compete on the exact same terms). Even though this rule can be voided in certain cases.