BSML’s Summary of Principles from:
SCRUM
By Jeff Sutherland
2014
From the BSML Business Wisdom Series
Introduction
Dr Jeff Sutherland is a graduate of West Point, ex Vietnam fighter pilot, PhD, consultant, author and latterly CEO of Scrum Inc.
He is credited with co-creating Scrum in 1993 with software developer Ken Schwaber and was one of 17 signatories of the Agile Manifesto in 2001, which marked the birth of “agile” in the technology sector.
The thesis of this book is that the way the world works is broken, and “Scrum” is transforming the way world-leading organisations operate, build software, manage projects, build teams and innovate. Productivity gains of 400% are routinely being reported, and therefore “twice the work is able to be done in half the time.”
BSML’s intention in compiling this summary is to share the wisdom of this innovator with our clients and prospective clients, to encourage them to read the full work, and to help them use its principles to improve management practices, technology ROI, and business performance.
Please feel free to share this link with your colleagues and friends, who have an interest in the topic.
Nick Bentley, Managing Director, BSML
“Agile” is a set of values developed in 2001 by 17 software development leaders
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
The principles of agile comprise
Contents
1. Context
1.1 The way the world works is broken
1.2 What is Scrum and what were its origins?
1.3 The power of teams
2. Key Elements of Scrum
2.1 Time
2.2 Waste is a crime
2.3 Plan reality, not fantasy
2.4 Happiness
2.5. Priorities
3. The process for implementing Scrum
4. Changing the world with Scrum
Appendix 1: Other agile software development methodologies
1. Context
1. Context
1.1 The way the world works is broken
1.2 What is Scrum and what were its origins?
1.3 The power of teams
1.1 The way the world
works is broken
• In 2001 the FBIs systems at that time were largely paper
• After 9/11 they embarked on a $270m modernisation plan called Virtual Case File to protect the nation. It would never be completed or used by a single operator
• In 2005 a new programme was launched called Sentinel, which would cost $451m and be completed by 2009
• By March 2010 the Sentinel system had cost $405m and needed a further $350m and 6-8 years to complete
• These calculations were based on very detailed Gantt charts and business requirements
• They used the “Waterfall method” of software development, which has 4 sequential phases, before the full set of software is delivered to the customer: Discover (business requirements), Design (technical specification), Develop (code and test), Test (client ok and launch).
1.2.1 “Scrum” is a framework, formalised in
1993, to avoid situations like at the FBI
• Its aim was to deliver “more stuff, in less time, with fewer people, and higher quality, at lower cost”
• Put another way… to develop working output/products fast and incrementally, based on highest value to customers
• Within 20 years it had become ubiquitous in software development including at companies such as Google, Amazon and Salesforce.com
• The framework mirrors how people actually work, rather than how they say they work. It covers uncertainty, creativity, learning, teamwork, checking and re-prioritisation of what the client wants, testing, focus, fixing delays and constraints, productivity improvement and measuring what matters.
• The results can be so dramatic that leading research firms such as Gartner, Forrester and Standish now say the old style of working is obsolete
1.2.2 Scrum includes concepts such as
• Product vision/output is delivered via 2-4 week sprint cycles
• Focus is on the 20% that makes up 80% of the customer value
• Sprint deliverables are finished/working increments of product
• Frequent product demos to customers to confirm value
• Product owner decides output; team deliver autonomously; scrum master coaches the team as servant leader
• Flow and velocity improvement are key measures of team efficiency. Co-location of full team, plus daily stand-ups aid communications, common purpose and integration
• Completion estimates only made when team velocity is known, based on work sizing and burn rates
• Systematic identification and removal of impediments/waste
• Focus on customers and stakeholders not developers
• Continuous improvement through process repetition
1.2.4 Key forerunner - 1983 HBR article “The new product development game” – Takeuchi and Nonaka
• Overlapping (not waterfall) development process is best (faster and more flexible)
• Cross-functional teams with autonomy make their own decisions
• Transcendent purpose bigger than individuals
• Executives as servant leaders and facilitators, with the sole role of removing obstacles
• The best teams act as if they are in a rugby scrum – the ball gets passed within the team as it moves up the field (the way humans work together best in any endeavour)
• The best teams can achieve 300-400% improvements in productivity (some 800% hyper-productivity), and can double the quality of their work
1.2.5 Influences from the USA
• Fired most senior managers in Japanese companies and promoted line managers from the ranks, with support from business operations experts like Demming from the US
• Training of hundreds of engineers
• Statistical process controls driving continuous improvement
• Habitual experiments and incremental, small changes
• Passion for advancing product quality and uniformity
• Actions over words
• Deming’s PDCA process – Plan, Do, Check, Act (check; don’t guess
This is how Toyota became the number 1 car company in the
world. It is also the foundation of “Lean”
1.2.6 Influences from Japanese culture
“Shu Ha Ri” points to different levels of mastery:
– Shu level – you know all the rules and forms and
can repeat them as if in a dance. You don’t deviate at all
– Ha level – you’ve mastered the forms, you can make innovations
– Ri level – you’re able to discard forms, you’ve truly mastered the practice, you’re able to be creative in an unhindered way, the knowledge is so deeply embedded your every step expresses its essence, motion seems effortless
1.3.1 The power of teams
Teams are what makes the world go round. Not individuals!
A great individual can outproduce a poor one around 10 times faster
A great team can outproduce a poor one by up to 2000 times (study of 3,800 projects)
Where should organisations invest
– individuals or teams?
1.3.2 The book identifies the common threads
for building super-performing teams
1. Transcendency – out of the ordinary sense of
purpose and what they are capable of
2. Autonomy – self-organising, self-managing, empowered
3. Cross-function – all skills needed, self-feeding and re-enforcing, “what’s best for the group” mentality
4. Self motivation and passion for excellence
5. Small teams – team size 7, plus or minus 2, is optimal
1.3.3 It provides case studies of great teams and what attributes made them great
• Boston Celtics/New England Patriots – playing a different game, doing the undoable, state of grace, could do no wrong, telepathy, absolute alignment of purpose and trust
• Canon – “when all team members are located in the same big room, someone’s information becomes your information, without even trying”
• Westpoint – facts, team ratings, transparency, higher purpose, “duty, honour, country”, history, transcendence
• Press team at Egypt uprising 2011 – team members decide how to achieve the strategic goals set by the organisation and within the constraints of the local environment, speed, autonomy, teamwork critical to meet deadlines
• Salesforce.com – diversity of skillset, thinking and experience, cross function, unselfish mindset, autonomy, team over functional specialty
• US Special Forces – all capabilities to carry out mission, team leader (strategy) and warrant officer (runs team), multiple skills to cover for casualties, no hand-offs, constant communication, extensive training
• All Blacks – haka, radical collaboration, refusal to accept defeat, celebrationof breakthroughs, obliterating barriers, speed, sense of culture and history
2. Key elements of SCRUM
2.1 Time
2.2. Waste is a crime
2.3 Plan reality, not fantasy
2.4 Happiness
2.5 Priorities
2.1 Time
• Time is the ultimate inhibiter of human endeavour. Our time on earth is limited. Best we use it well and focus on the things we love best!
• At Media Lab in the early 1990’s, they built all sorts of cool stuff using “sprints” – every 3 weeks each team had to demonstrate what it was working on to its peers. If it wasn’t working and cool, the project would be killed. Time is money. Wasted time is wasted money.
• Sprints evoke speed and are standard (1 to 4 week) boxes of time. They evoke work rhythm and also show acceleration of output over time as the team becomes more cohesive and efficient.
• Time boxes are filled with the work a team believes it can get done in the time available (ideally in priority order). Tasks are locked in and don’t change. Sprints are a constant duration
• Scrum boards show what is “to be done”, “being done” and “done” Done means fully working and usable by a customer
• Daily team meetings last 15 minutes maximum. They are about communicating progress and identifying barriers to completing the sprint
• Dependencies on other people are the massive time wasters. Eliminating them is a key focus of Scrum meetings
2.1.2 The SCRUM board
2.1.3 Burn down chart – daily work remaining
2.1.4 Key takeaways on Time
Key takeaways on Time• Time is finite – use it well and call it a sprint
• People like rhythm in their lives – sprints provide this along with a sense of achievement and variety
• Demo or die – produce something that is useful to a customer, cool, complete and working in every sprint
• Throw away your business cards – specialisation over team is a status marker. Be known for what you do, not your title
• Everyone knows everything – communication saturation accelerates work
• One 15 minute meeting a day – see what can be done to increase speed and do it
2.2.1 Waste is a crime
• “When I go into a company I usually find that 85% of effort is wasted. Onlyabout a sixth of any of the work done actually produces something of value”
• Toyota’s Taiichi Ohno said: “waste is a crime against society more than a business loss”. It comprises Muri (unreasonableness/ over-burden), Mura (inconsistency/unevenness) and Muda (the 7 wastes – inventory, waiting, defects, over-production, motion, transportation and over-processing)
• Unreasonableness/over-burden is linked to getting people to do the absurd or impossible, rather than providing challenging but achievable goals, which help people grow
• Inconsistency/unevenness is associated with the need for heroic action, crisis and burn-out from unrealistic objectives, resources or timeframes
• Wastes include onerous company policies, unnecessary reporting or form- filling and meaningless, unfocused meetings, which consume huge amounts of time for no client or business benefit
• Effortless flow in creating exactly what the customer wants is the ultimateuse of time. This coupled with discipline enables amazing things to happen
2.2.2 Key takeaways on Waste
• Multi-tasking makes you stupid – doing two things at once makes you worse and slower at both
• Half done is not done at all – it uses time, money and energy, whilst delivering nothing of value
• Do it right first time or fix it immediately – delaying a fix can take you up to 20 times longer
• Working too long only makes more work – working long hours gets less work done
• Working too hard makes more work – through errors and re-work.
• Work fresh and at a steady rhythm. Take breaks and holidays
• Goals that are challenging motivate.
• Heroic working is a planning failure.
• Eliminate stupid policies and work that adds no value to clients.
• Avoid assholes who create unnecessary work, distraction or conflict
• Maximise flow
2.3.1 Plan reality not fantasy
• Most project managers think they can plan and estimate well. We are almost universally wrong on the side of over optimism (see the cone of uncertainty 2.3.2). The map is not the terrain. Terrain dictates speed
• Refine your plan regularly. Do the 20% most important things (to the client) first. Get regular client feedback and adjust. Only plan the next sprint in full detail. As more sprints are completed velocity gains will compensate for poor early estimation, and lower value items (some of the 80%) can be eliminated from scope
• Task estimation is best done via relative sizing (not absolute time estimates) and value – ideally based on Fibonacci (1,2,3,5,8,13,21 etc) or T-shirt sizes (S,M,L,XL). The total points per sprint give a sense of value and effort and will provide a baseline for improvements in sprint velocity.
• Estimation by the whole group is better than one person. Use repeated anonymous surveys (Delphi). Dissenting voices should be encouraged and heard to avoid groupthink and halo effect (giving false positive attributes to a person based on first impressions)
• Another approach is “Planning poker”, which uses cards with Fibonnaci numbers for the team to size each task and eliminate the extremes
2.3.2 The cone of uncertainty for software time and cost estimation
2.3.3 Stories not tasks
• People relate to stories
• So to arrive at the best definition of tasks, Scrum requires tasks to be written with a who, what and why (x wants y so they can do z)
• Who details the customer. What details the output. Why explains how the output will satisfy the customers need
• This process removes unspoken assumptions that might result in the output not meeting the need
• Examples of stories include: “As a customer, I want to browse books by genres, so that I can find the type of books I like” or “As a product manager I want to be able to track a customer’s orders so that I can market specific books to customers based on past purchases.”
• Stories for different users may be aggregated into an overall story or “Epic”, which, in the above case, may be about “creating an online bookstore”. The team should engage on the best way to deliver this in aggregate
• A project may have a number of Epics that make up a whole deliverable of maybe “the easiest bookshop in the world to deal with”
2.3.3 Completeness of stories is key to velocity
• INVEST is the mnemonic for checking stories are complete
– Independent – is the story stand-alone and not dependent on others?
– Negotiable – allowance for changes to the story is built in
– Value – it must deliver value to a customer or stakeholder
– Estimable – the effort can be sized
– Small – able to be estimated and planned for – if not break it down further
– Testable – the story must have a test it can pass to demonstrate completeness. This should be done before doing the story
• To be ready a story must be complete and meet the INVEST criteria
• To be done a story must pass the test (T in INVEST)
• If stories are ready at inception, sprint velocity can be doubled
• If stories are compete at the end of the sprint, velocity can be doubled again
• Stories for different users may be aggregated into an overall story or “Epic”, which, in the above case, may be about “creating an online bookstore”. The team should engage on the best way to deliver this in aggregate
• Incompleteness causes work and re-work and should be eliminated.
2.3.4 Impediments to velocity
• Unnecessary features
• Poor prioritization
• Excessive sprint scope
• Missed dependencies leading to delays
• Incompleteness of stories – documented, ready, and done
• Not empowering people to make decisions
• Onerous technical requirements
• People not showing up to meetings
• Team not working in the same room
• Process, personality, and procedural problems
• Inefficient technology
• People/skill gaps
• Sequential, rather than parallel work
• Out-sourcing opportunities missed
2.3.5 Key takeaways on
plan reality not fantasy
• The map is not the terrain – things will get bumpy. Your plan is almost certainly wrong and over-optimistic – recognise this
• Humans are very bad at estimating – size tasks relatively with Fibonacci or T shirt sizes (S, M, L, XL, XXL) and get good at estimating
• Only plan what you need – just plan enough to keep your teams busy
• Ask the Oracle – use the team, do rounds of anonymous surveys (Delphi) to avoid biases, groupthink, and halo effect. improve consensus and estimation accuracy over time
• Plan with poker – to quickly estimate task sizes using Fibonacci playing cards
• Stories tell you who wants the work, what they want, and why (x wants y so they can do z)
• Know your velocity by calculating points for work done per sprint.
• Improve velocity by removing impediments and waste
• Velocity x Time = Delivery date – calculate completion as your estimation improves, not at the start
• Set audacious goals as productivity increases and impediments disappear
2.4.1 Happiness
• People want to be happy at home, at play and at work … in an active way
• “Pursuits do seem to be what makes us happy” said Thomas Jefferson
• Most of our days are taken up striving towards our goals
• Mountain climbers are happiest when pushing their body, mind and spirits to their limits. Reaching a summit is fleeting and just part of happiness
• Paradoxically society rewards results not processes, arrivals not journeys, and yet happiness is a critical part of success in all life’s endeavors
• Studies show that happiness in fact precedes important outcomes and is a predictor of success. Small gestures can have great impact
• Continuous improvement or “kaizen” at Toyota makes people happy
• This is reflected in Scrum through:
1. Team responsibility for process, outcomes and solutions
2. Fixing little things routinely as soon as identified
3. Regular customer and stakeholder feedback
4. The concept of “Done” before shipping
5. Sprint retrospectives to identify the good, bad and improvement priorities
2.4.2 Maslow’s hierarchy
of needs supports this
2.4.3 Great teams demonstrate
• Autonomy – control over their own destiny
• Mastery – the feeling of getting better until the work is second nature
• Transparency – everyone knows everything, in Scrum through:
– Daily stand-ups
– Self organisation and problem solving
– Open stakeholder meetings that anyone can attend
– Scrum boards of tasks – to do, in progress, in testing, done
– Retrospectives – end of sprint reviews, including teamwork and
performance
– Co-location of team – nothing done behind closed doors
• Teamwork – efficient and effective processes and collaboration
• Connection – closeness, respect, trust, shared goals, support
These all contribute to a positive, collaborative, productive, innovative, and
high-performing team culture. If team members are helped to thrive and
achieve mastery of their skills, it will quickly lead to joy and self-fulfillment.
2.4.4 The happiness metric
4 questions for each team member at the and of each sprint:
1. On a scale of 1-5 how do you feel about your role on the project or in the
company?
2. On the same scale, how do you feel about the project or company as a
whole?
3. Why do you feel that way?
4. What one thing would make you happier in the next sprint?
This is done as a team and enables really insightful conversations about
continuous improvement.
The team then selects the most important improvement/kaizen to make
and test in the next sprint.
If teams do not continuously improve, they can get complacent (the 2004
US Olympic basketball team is an example). This can lead to an
“entitlement culture”, productivity plateau, decline in teamwork,
unhappiness, dissent and ultimately team break-up.
The antidote is to measure progress against the goal, sprint velocity gains,
and confront complacency and entitlement head on.
2.4.5 Measuring team happiness
2.4.6 Insights into how people approach
the world – 4 types of people (Ben-Shahar model)
2.4.7 Key happiness takeaways
• It’s the journey, not the destination, the process not the result that makes us happy. Reward people striving towards greatness, not just end points
• When you’re happy you’re more creative, more productive, will achieve higher and are less likely to move on
• Happiness is a predictor of future results. Measure it at individual and team level
• Get better every day and measure improvement within your Scrum processes. At the end of each sprint let the team pick a priority improvement for the next sprint
• Secrecy is poison. It only serves people who serve themselves. Make everything transparent. Let everyone know everything including pay rates
• Make work visible by having a Scrum board that everyone updates every day. All meetings to be open to stakeholders
• Happiness is autonomy, mastery, and purpose. Everyone wants to control their own destiny, get better at what they do, and serve a purpose greater
than themselves
• Complacency is the enemy of success. Measure team happiness against
performance and pop the happy/complacent bubble.
2.5.1 Priorities
• If a business is not making money, it’s a hobby
• If a project delivers something that no one wants it’s a waste of time, effort, opportunity and money
• The power of Scrum lies in combining:
– What the team can deliver;
– What it can sell;
– What it is passionate about;
– What it can clearly envision; and
– A backlog that is properly prioritized
• 80% of the value of any project lies in 20% of the work. So do that first!
• Determine what things have the greatest value to the customer, biggest business impact, highest return on investment for you, and are the easiest to do – the sweet spot.
• Do those first and make sure they are complete (or demonstrably “Done” in Scrum-speak)
2.5.2 The product owner
• The product owner decides the what:
– The vision
– The backlog
– What order the backlog should be done in
• He/she splits time equally between:
– talking to customers to determine value, priority, and completeness; and
– talking to the Scrum team to ensure that what is built is of greatest value to
the customer
• Essential characteristics of a product owner are:
– Knowledge of the domain (customers, markets, products, competition)
– Authority to make decisions (product vision, features, approach)
– Availability to the team (to explain what needs to be done and why)
– Accountability for delivering maximum value or return on investment
• Market intelligence, visioning, prototyping, minimal viable product, and customer testing/validation are key tools of the product owner
• The product owner ultimately translates the team’s productivity into value
2.5.3 The product owner owns the
product development OODA loop and
seeks to optimise it
2.5.4 Maximising value with the least effort
is key to the 80:20 rule and also Scrum
2.5.5 Having delivered 80:20, a team may be better finding the next 80:20 elsewhere
2.5.6 Early termination clauses can be a win win
• Payment based on full quote plus variations
• Incentive to bid low, find variations, complete full time
• No incentive for speed or maximising value
• Payment based on value delivered
• When client happy with value sufficiency, contract can be terminated
• Contractor gets say 20% of remaining contract value for free
• Both parties get more for less effort
• Incentive to deliver maximum value in least time
2.5.7 Managing risk
• Managing risk is at the core of every successful venture
• There are 3 most common risk types – market, technical and financial risk
• Market risk is minimised by incremental delivery and fast feedback from customers
• Technical risk can be minimised by rapid prototyping of many designs and getting customer feedback on the best
• Financial risk is dependent on the scale of investment. Scrum minimises upfront investment in product design, but all costs of getting the product to market and sustaining it make any venture a financial gamble.
• Software products are lower risk than physical products, but business models based on free and advertising revenue have long ago saturated the market
2.5.8 Key takeaways on priorities
• Make a list; check it twice – list everything that could be done on the project, then prioritise it by highest value and lowest risk
• The product owner translates vision into backlog and needs to understand the business case, the market and the customer
• A leader isn’t a boss – the product owner decides what needs to be done and why; the team decide how it is accomplished and by whom
• The product owner has knowledge of the domain and the power to make final decisions. He or she is available to the team to answer questions and is accountable for delivering value
• Observe, orient, decide, act (OODA) – see the whole strategic picture but act tactically and quickly
• Fear, uncertainty and doubt – get inside your competitions OODA loop and wrap them up in confusion
• Get your money for nothing and change for free – create new things only if they add value. Be willing to change priority. What you think you need at the beginning is not how it will look in the end
3.The process of implementing Scrum
1. Pick a product owner – someone with vision, who knows the market, its risks opportunities and participants, can assess what will make money, beat the competition and be sustainable
2. Pick a team – with all the skills to turn the vision into reality and ideally between 3 and 9 team members (no more)
3. Pick a Scrum Master – who can coach the team in the methodology and help the team eliminate anything that will slow them down
4. Create and prioritise a Project Backlog – A high level list of everything that has to be done to make the vision a reality. It includes everything that could be done, ranked in order of priority/value by the Product Owner following consultation with stakeholders
5. Refine and estimate the Project Backlog – done by the people who will do the work, is it doable, small enough to be estimated (based on relative size of tasks, T shirts or Fibonnacci (1,2,3,5,8,13). This initially sizes the project.
6. Sprint planning – first Scrum meeting (team, PO, SM) considers the top of the backlog, length of sprints (>1-2 weeks <4), how much the team can do in the first sprint, and aggregate value points if delivered as planned. Points per sprint indicate velocity. Once set, things can’t be changed. The sprint goal is to be set by the team and delivered autonomously by them
3.The process of implementing Scrum (cont.)
7. Make work visible – normally using a Scrum Board with 3 headings (to do, doing and done). Sticky notes represent the items to be competed, which are progressed through the categories. Burn-down charts track work remaining in terms of points and days effort
8. Daily stand-up meeting – same time each day, maximum 15 minutes total, whole team reports individually 1. What did I do yesterday to help the team complete the sprint? 2. What will I do today to help the team complete the sprint 3. Is there any obstacle blocking me or the team from completing the sprint? This communicates status, highlights slippages and enables the team to help members who are struggling or behind. There is no detailed reporting to management. The Scrum Master as servant leader has the sole role of making impediments go away
9. Sprint review or demo – this is the meeting where the team shows what it has moved to “done” i.e. features of the product that are totally and completely finished. Any stakeholder can attend and provide input and ideas.
10. Sprint retrospective – at the end of each sprint, the retrospective looks at what went well, what could have gone better for the next sprint and what is the improvement in process the team can implement today – what did we not foresee, what didn’t go as well as it could, what slowed us down, what’s bothering me? The team and Scrum Master should then agree on one process improvement to implement immediately.
Pictorially the Scrum framework has evolved to look like this
4. How Scrum has changed the world
4.1 Other uses in the book
4.2 Dominance in software development (2011)
4.3 Dominance in software development (2020)
4.4 Other agile frameworks
4.5 Pros and cons of using Scrum
4.1 Change the world!
• Scrum has taken root in software development but Jeff
Sutherland in the final chapter advocated that it can be used
in any endeavour to improve performance and results, citing
the following examples:
– Netherlands – Scrum for schools used by numerous teachers to teach high school students and equip them with 21st century team skills. The kids self organise, research subjects, delegate work, help each other and those less gifted, and learn to collaborate and value each other’s strengths, with only coaching on the process from their teachers
– Uganda – Scrum for poverty enabling poor rural farmers to mobilise, gather and disseminate agricultural and market data amongst themselves to enhance their yield and margins, which were previously controlled by middle-men and large conglomerates
– Grameen Bank – a microfinancier of the poor, which encourages and finances community projects in poor countries. It requires loans to be re- paid and business cases delivered by project teams before bigger projects will be funded.
4.2 A 2011 survey indicated the following market mix
4.3 Current mix looks more like this
4.4 Each agile framework has its own philosophy, characteristics and terminology
4.5. Pros and cons of using Scrum include
Pros
• Focuses on value, velocity, teamwork, happiness and eliminating waste
• Clear roles, responsibilities, rituals
• Philosophy of learn by doing, self determination and servant leadership
• Builds productive teams through product clarity, empowerment, process, coaching, prioritisation, time pressure, repetition and testing of “done”
• Reduces team sizes significantly (3-9)
• Scrum board makes status transparent
• Nice supporting techniques and visuals have been developed since the book
• Dominant market position/brand awareness as a methodology
• Strong antidote for large projects with large teams and large budgets, which normally go off the rails or fail to deliver
Cons
• Remains largely a software method
• Still requires experience, leadership and skill from the product owner and scrum master
• Scrum has gone from a fairly simple framework to a global training industry, somewhat bureaucratised, formulaic, dogmatic and commercialised
• The processes can become tedious and a turn-off after a while
• Innovation and common sense can be lost in the routine
• Good executive sponsorship remains key to all projects’ success
• There are many failed Scrum projects
• There is no substitute for smart, experienced, talented people who are empowered and well supported
Ultimately the principles of agile, rather than
the process is what underpins success
CONTACT US
We work to respond to your enquiries as quickly as possible.
Email: Info@bsml.co.nz
Tel: +64 (027) 454 9315
Office: NTT Building, Level 16, 157 Lambton Quay, Wellington