The Agile approach to project management is at least fifteen years old and borrows concepts from older methods. An Agile approach takes on an iterative approach to software delivery as opposed to the waterfall approach. Agile project management works by breaking projects into little bits of user functionality called ‘user stories’, prioritising them and continuously delivering them in two-week cycles. Agile is actually umbrella term for several iterative and incremental software development methodologies, such as Extreme Programming (XP), the Scrum Method, Dynamic Systems Development Method (DSDM), Lean Development, and Feature-Driven Development (FDD). We look at one Agile Framework, in particular, the Scrum methodology.
A Short History Of Agile
In the late 1990’s, several methodologies began to gain public attention, each having a combination of old and new ideas. These methodologies encompassed close collaboration between the development team and business stakeholders. Frequent delivery of business value, tight, self-organizing teams; and smart ways to craft, confirm, and deliver code. The term ‘Agile’ was applied to this collection of methodologies in early 2001, when 17 software development practitioners gathered in Snowbird, Utah to discuss their shared ideas and different approaches to software development. The joint collection of principles and values was called the ‘Manifesto for Agile Software Development and it’s 12 principles.
The Fundamentals Of Scrum
- Work is split into small, manageable tasks.
- The team pick a few tasks to tackle in a sprint
- Progress is assessed at the end of the sprint, a working, prototype/concept or part thereof, should be presentable.
- A sprint ends with a review and a retrospective.
- The next sprint begins slicker and better than before.
- Projects delivered on time and on budget.
The Key Concepts Of Scrum
Out with the old and in with the new
- Waterfalling and Gantt charts are outdated and imprecise.
- The map is not the terrain, don’t fall in love with your plan.
- Only plan what you need to, don’t be years ahead.
Build into your working method the assumption of change, discovery, and new ideas.
- Inspect and Adapt. Stop, review, and see if you can do it better.
- Change or Die.
- Fail Fast so you can Fix Early.
Where did it all come from?
1986 HBR paper: “The New New Product Development Game”
- Authors: Hirotaka Takeuchi and Ikujiro Nonaka.
- Highlighted the importance of cross-functional teams and a faster, flexible way of working.
Toyota Production System
The precursor of the more generic “lean manufacturing”.
Taiichi Ohno and Eiji Toyoda developed the system between 1948 and 1975.
OODA: Observe, Orient, Decide, Act.
Know where you are, assess your options, make a decision, and act!
Plan, Do, Check, Act.
Plan it. Do it. Check whether it did what you wanted. Act = Change.
Teams shouldn’t be greater than 7 members ± 2 (Min. 3)
Too many resources make the team go slow. (Basically, too many cooks spoil the broth.
Brooks Law – Adding power late, makes it later.
Great Teams Are
Cross-functional – Are equipped with all the skills to complete the project.
Autonomous – Gives teams the freedom to make their own decisions.
Empowered – Gives teams the ability to act on those decisions.
Transcendent – Have a purpose that is greater than themselves
.“A team has to demand greatness from itself.”
Communication is Key
Everyone knows Everything, communication saturation accelerates work.
- The Sprint: building working features one by one.
- Questions to ask in the Sprint:
1.What did you do since the last time we talked?
2.What are you going to do before we talk again?
3.And what is getting in your way?
THIS IS A CONTINUOUS EXERCISE THAT ALSO MAKES UP THE DAILY 15 MINUTE MEETING.
a.Backlog – ALL the work that needs to be done.
b.To Do – Current sprints worklist to be completed
c.Doing – Work in progress from current sprint.
d.Done – Work completed
e.Demo or Die. At the end of each Sprint, have something that’s done, something that can be used or demonstrated to those that matter.
Three Scrum Roles
Product Owner – What the work should be, translate productivity to value.
Scrum Master – How the work should be done.
Team member – Does the work.
Translates the vision into Backlog.
Must understand the business case, the market, and the customer
Should have everything on it.
Prioritise it. Items with
value and lowest risk at the top of that Backlog.
Find out the 20% of input that yields 80% of the output.
“Figure out where the most value can be delivered for the least effort, and do that one right away.”
Waste is a Crime
Do one thing exclusively before moving onto another project.
Multitasking makes you slower and worse at both tasks.
Focus on completing one thing before moving onto another.
“Doing half of something is essentially doing nothing at all.”
Do things right the first time.
Fix errors and bugs right away.
Alternatively, spend two weeks trying to find your mistakes… NOT AN OPTION!
Strive for Flow.
Choose the smoothest, most trouble-free way to get things done.
Scrum is about enabling the most flow possible.
Set realistic Goals.
Goals that are challenging are motivators.
Goals that are impossible are just depressing.