Send the link below via email or IMCopy
Present to your audienceStart remote presentation
- Invited audience members will follow you as you navigate and present
- People invited to a presentation do not need a Prezi account
- This link expires 10 minutes after you close the presentation
- A maximum of 30 users can follow your presentation
- Learn more about this feature in our knowledge base article
Agile Orientation Pack
Transcript of Agile Orientation Pack
Why Are We Going Agile?
The Terrible Mer-Cow
This pack describes the Agile SDLC in detail. It covers
roles & responsibilities
motives and metrics
Reading about Agile can't make you an Agilist any more than watching a TV show makes you an iron chef.
Agile is something you learn by doing. It's like learning to cook properly - you need to hang with a chef. But the ingredients are simple.
We'll start with some basic ideas about what to do.
Don't Be Fooled ...
And what not to do.
Agile recognises that technical debt destroys team productivity.
So time pressure doesn't mean no time to do it properly.
Time pressure means no time to do it quick and dirty.
Agile practices collective ownership of all products. Code, tests, specs, docs, everything belongs to the whole team. If code's unmaintainable, that's debt - the team owns it and pays it.
We're all professionals here. We can figure out how to collaborate to get better outcomes than any one can produce by themselves. Peer review is good, but pair working is better.
Agile is a standard method of teamworking. Our local social and technical conventions are written in a project charter. You don't like how I'm working, the team resolves our differences.
Agile continuously reflects on the way we work. We have a retrospective meeting every week on what's working for us and what's not. We clear the air and decide together how to improve.
Testing? We don't code except solutions to tests. All tests are automated with testers and devs pairing. All tests run in CI with every checkin - which is how we know we're producing quality.
Agile is a high discipline process. It measures, tests and reviews everything all the time. A cowboy, no matter how technically strong, has to change his outlook to support an Agile team.
Agile generates transparent self-organisation. Managers are still an essential part of the process, but they become "servant leaders", smoothing communications and removing roadblocks. They don't give orders to the team. They take orders from the team. Including for coffee.
I manage variances to the baseline.
I push the team down the critical path.
I am accountable. I am in charge.
My anxiety motivates the team.
I plan what you do. Also when and how.
Agile means I tell you how high to jump.
Quick and dirty. No time to do it properly.
No one but me should ever edit my code.
I know how business works without asking BAs.
You not liking how I work is your problem.
Testing? We pay testers to do that.
Agile means code first, ask questions later.
Hold Your Horses!
V I S I B I L I T Y
Waterfall projects are transparent at the start with all their plans, analyses, designs and budgets. And they're transparent at the end when the product is integrated and tested. But they have a long, dark, surprising middle.
Agile standups, showcases, retrospectives and information radiators mean everyone concerned with the project knows what's going on all the time. Agile keeps the team aligned with the business. Any surprises are little ones.
A D A P T A B I L I T Y
Waterfall analyses, plans, and designs everything up front. If something changes, that's expensive. The later in the project, the more expensive.
Agile flattens the cost of change. It eliminates functional dependencies with architectural spikes ahead of production code. It validates all assumptions with test-first test-driven development. And it delivers complete features one after another, continuously integrated. So the project plan can always be reshuffled to reflect changing business needs.
Agile generates complete features one after another. The most valuable features are delivered first so there's plenty of time to fine-tune them to fit the Product Owner's vision. When sufficient business value has been delivered to make a release, Agile is ready to make that release. Releasing early and often generates continous business value.
Waterfall keeps a large inventory of incomplete, unintegrated work in progress through most of the life of a project. Work is delivered by subsystem rather than by feature. It can't be fully tested and integrated until long after it is developed. So it just sits there, valueless, for a long time.
Agile systematically classifies each requirement in terms of technical risk, non-functional envelope and business dependencies on external groups. It mitigates technical risks through architectural spikes, and business risks through deferring high-risk features till later in the project. Agile validates all assumptions through automated tests, so problems in emergent system behaviours are caught the very first time they appear.
Because Waterfall details designs without prototyping, and because it integrates in a big bang just before testing, it carries risk through the life of a project. It also risks technical lock-in as design is completed in a phase before tests determine non-functional suitability of key design decisions.
& Scrum Master
An Agile PM is a lot like Captain Kirk. Focused entirely on the success of the project, shielding the team from political forces but representing the team to the business, seeking out new strategic opportunities, facing down tactical risks, boldly going ...
The Scrum Master is more like Doctor McCoy. Pragmatic, approachable, focused on fitness for duty of the team and its environment. A good Scrum Master seeks out and resolves project stressors, connects team members to each other, and works on improving reliability and productivity in the way the whole team works.
Forget siloes. The Agile team includes Devs, BAs and Testers all working together as a cohesive whole.
Ideal team size is 8 +/- 2 professionals. They're not accountable to line managers. No external dependencies or inter-role politics. Every person in the team relies on and takes care of the others.
When a Dev needs a hand tracking down a bug a Tester will help. When a Tester isn't sure about a user behavior, the BA will jump in. And when a BA needs a hand sorting out some tech spec, Devs come to their rescue. No one throws stuff over the wall at someone else. All for one, one for all.
Pair working is the most common mode on an Agile team. It makes better quality work and keeps us connected. And that makes certain what we do hangs together too.
& Tech Architect
An ideal Product Owner is like Mr Spock, evaluating opportunities and risks in the market place, quantifying targets, prioritising the way forward. He offers regular reliable feedback on the commercial reality of the project and the culture of competitors. He's accountable for keeping the team focused on what it needs to get done to accomplish its mission.
Like Scotty, the Tech Architect is accountable for all equipment the team needs to use to deliver. Domain patterns, application architecture, test infrastructure, version control conventions, environment management, services, interfaces ... the Technical Architect worries about the whole thing, not just parts of it. He also helps the PM and Product Owner figure out what's technically feasible so they don't try to do things that can't work.
We plan releases in Themes and Epics.
A Theme is one of the big bones of a project. The GUI, for example, or Security. Themes are the really high level aspects of a product.
An Epic includes a Use Case, but there's more to it. A Use Case is just functional design - it describes the system interface. An Epic is also a solution design and a block of work we can estimate.
Each Theme splits into a bunch of Epics. The Agile release plan is a map of Epics to milestones.
The Agile team finishes off one Epic at a time with a minimum of work in progress - so there's no functional dependencies to juggle. And the team members are on each Epic full time - so the team has a constant burn rate. You don't really need a Gantt for something as simple as an Agile release plan - a calendar will do. But Gantts can still be handy ...
In each release the team delivers everything needed to drop its Epics into production - tests, docs, training collateral, the works. That's the "definition of done" for an Epic. Themes don't have a definition of done - you can always do more - but returns diminish.
Refactoring means improving the design of existing code. Agile projects are free to refactor because Agile builds up a complete library of automated regression tests as it goes - no production code is ever created except to solve an automated test.
So the basic rhythm of Agile delivery is "test a bit", "code a bit", "refactor a bit". Refactoring clarifies and reduces the number of lines of code necessary to make all existing tests pass.
Agile maximises ROI - Return On Investment. The "Baseline" is just a first guess at that return. It's not sacred and we don't manage to it. We manage to meet changing business needs.
Agile obsoletes central planning ideas about "critical path". Functional dependencies are just technical debt in disguise. They're eliminated through spiking and refactoring.
An Agile manager is a part of the team and accountable to the team. He is their representative, not their boss. He focuses on finding ways to help them produce. He doesn't own them.
Agile changes responsibilities for all team members. Team members are equally accountable for team outcomes. Like the famous musketeers - all for one, one for all.
Managers don't plan for the team. The team plans for itself in a weekly conversation with the Product Owner. But managers resource, budget, remove roadblocks and align expectations.
Agile team members drive each other to improve the quality and productivity of their output. They strive to excel. Managers need to feed the Agile team rather than push it.
A "Spike" is a throwaway prototype created to gain knowledge. We do just enough spiking to gain sufficient knowledge to be able to estimate technical tasks. No more.
And we throw away our spikes because they're not produced to production quality standards.
Release planning assigns epics to releases. Each release starts with a "pre-game"
phase where the team breaks the release's epics into stories in a Product Backlog.
An epic is a generator of stories. If the Theme is Security, an Epic might be "Role Based Access Control" and a Story might be "User logs in".
We estimate stories at a fine grain, no more than a couple of effort days per story, where the scope of an epic might be multiple effort-months. The unit of estimation is the "story point".
A story point can be thought of as some amount of ideal time but in practice it's better to estimate stories in terms of relative difficulty. Some small, well defined story is used as the standard and the other stories are ranked according to whether they are more or less difficult than that.
The Product Owner and Tech Architect prioritise stories by business value and risk. The Product Backlog is the complete list of prioritised, estimated stories.
Every week or two, depending on team preference, the team runs a sprint. Which is to say the team commits to deliver a number of stories in that period.
How many stories? We look at how many story points the team was able to deliver in the last couple of sprints. We might vary that "recent weather" to account for holidays and new hires. The team can easily figure out what it's willing to commit to deliver on the timeframe of a week or two.
The Sprint Backlog is a cut of stories taken off the top of the Product Backlog whose size equals the team's commitment in story points. At the start of the Sprint the team plans how it will deliver those stories - breaking them into individual technical tasks, looking at what must be spiked or mocked, and signing up to lead particular tasks.
Sometimes stories have to be delivered in an order that cuts across their natural technical dependencies.
When this happens we create a bit of test automation called a "mock object". This is a stub for the dependency that describes expectations about how it's to be used. Our test frameworks are so smart they automatically check these expectations, ensuring we don't break 'em until we replace 'em with the real thing.
Once controversial, Test Driven Development has become the standard method for production-quality code in the 21st century.
Programmers always wrote unit tests as "main programs" during code development. But they'd throw them away. Under TDD we name them to reflect their intent and keep them as automated regression tests.
TDD means creating a test first, making certain it fails, then writing the code that makes it pass. This does more than generate a complete regression test suite. It enables collective code ownership and design by refactoring, key collaborative disciplines that dramatically boost code quality and readiness for change.
Acceptance Test Driven Development is less well understood than TDD but in many ways more powerful. Where TDD assures programmers that their code does what they think it should ATDD assures Testers, BAs and the Product Owner that the system interface does what they think it should do.
ATDD generates a Domain Specific Language (DSL) to describe system behaviors through a combination of structured english and tables. A DSL is a kind of API for testers, enabling them to put the system into well defined states, make assertions about behaviour in those states, and clean up afterward - all without requiring Devs to code the tests.
Devs jsut produce code to underpin the DSL. There are various frameworks that enable this. One popular choice is a tool called Cucumber but the tools landscape is constantly changing. The ultimate aim of ATDD is to enable BAs and Testers to make all specs executable - which is the best way to be certain the delivered product satisfies them.
If peer review is good, continuous peer review is better. Pairing, the practice of two team members sitting side by side at the same keyboard and producing deliverables together, remains the most controversial practice in Agile. Many teams take to it like ducks to water, but it is common that more conservative team members push back against pairing, declaring it time consuming or disruptive.
So it's best to encourage rather than require the team to pair. For team members who take the time to learn how to make pairing effective, the benefits are obvious. It dramatically improves productivity, reduces debugging time, ensures the standardisation and maintainability of the code and tests, and spreads problem and solution domain knowledge throughout the team. Plus it's fun.
Many teams rotate pair arrangements every day. The highest quality software is generated by teams who refuse to accept code written by individual developers. There are occasions when single-handed coding is a better solution - especially when spiking. And it is better to let conservative team members work independently than to force them to pair if they don't want to.
Standup meetings appear almost trivial. The team stands in a circle for ten minutes once a day every day. Members discuss what they did yesterday, what they intend to do today, and who they need to help them today. If they've hit a blocking issue, they raise it but any issue that will take more than a couple of minutes to discuss is taken off-line.
The benefit of Standups is in what the team does not do. The team doesn't have any other daily meetings. The team doesn't have different members repeating the same tasks And the team doesn't lose its focus.
Standups are the only time every day that the team really is a team. So they create a social context for the work that can't exist any other way.
Continous Integration began as a simple way to making certain slow-running or large-data tests pass. Every time a developer checks their code into the VCS, the CI server checks it out and runs it against all the tests in the whole project. If any test fails, a display lights up in red and the CI server emails the team to make certain they fix the failing test. Simple, right?
But CI can be a lot more than this. CI is used by multiple different projects to deliver code to each other while making certain shared components are not broken by conflicting stories. It is used by operations and development teams to ensure that production fixes for one release are folded into the development of the next release. Decentralised CI works as a system of semaphores to ensure the enterprise as a whole has a functioning check on relationships between critical information systems.
From the point of view of a SCRUM team, CI is simply the best way to make certain that the defect rate stays at zero and the deliverables are constantly in a state where they can be released if desired.
Agile is made possible by modern version control systems (VCS), which no longer require team members to lock out each others' changes as they work. Each dev checks out their own copy of the code, works it until their task is completed, and then checks it back in again. If some other devs checked in changes in the meanwhile, the affected dev merges those changes into their copy of the code, fixes any broken tests, and checks the merged work back into the VCS.
If you're not familiar with merging VCS this sounds like a recipe for trouble. In fact it's a method proved in trillions of lines of code over 2 decades. It is the dominant model for VCSes today. Some VCSes take it even further and decentralise it - that's not strictly necessary to do agile, but merging is.
Agile leverages merging to enable a new kind of design process called "Refactoring". When a pair of devs have coded the solution to a story's tests, they take a step back and look at the effect of their work on the codebase as a whole. Have they duplicated functionality? Can they simplify old code using the new code? Have they superceded tests? They wind up editing lots of other peoples' code to make the system as simple as possible while still making all the tests pass.
Since all the team members are constantly refactoring all the code, the design of an Agile codebase gets better and better over time. In fact the codebase really IS the design, at least at a micro level. There are no great big diagrams with bubbles and arrows in Agile. Refactoring works better than big diagrams. It keeps the code perfectly balanced, ready for change. But it requires designers to be technically literate.
Information radiators display the project's burndown chart, cardwall and CI status in public places where they motivate people inside and outside the team.
The card-wall shows how each epic, story and task flows through the sprint workflow. It's a live view updated in real time.
The burn-down chart tracks progress against commitments. The red diagonal line shows the commitment over time. The green line is measured project velocity in story points per day.
The CI dashboard shows the number of passing and failing tests over time.
Agile provides a lot of new tools and processes focused on automated deployment. Virtualisation makes it possible to clone environments including multiple servers in all kinds of technologies. Test and production server farms can be made elastic, and data centers have become a cheap and elastic commodity. Database migrations - transformations on schema and data population - are versioned along with application code and tests.
This is all to the good. Agile is relatively expensive in terms of environments. It is typical for Agile developers to each have their own complete development environment, for CI to use another, and for testers and devs to each maintain a production snapshot for manual integration testing. Automated deployment from VCS is critical to coordinate the flow of artifacts between all these environments.
At the showcase the team demonstrates the stories delivered in the last Sprint. The PM and PO invite customer representatives and technical and business authorities to attend. Feedback is gathered by BAs for each demonstrated story and this feedback is prioritised, estimated, and inserted into the Product Backlog.
After the Showcase the team gets together with no customers or authorities to discuss what went well, what didn't go well, and what to do differently next Sprint.
This is a very frank and open exchange. The Scrum Master manages the meeting as a brainstorm to keep tempers cool. No blame or shame is involved - just problems, proposals and resolutions.
The Retrospective does its work in 2 passes. The first canvasses each team member for their feedback. The second is actions to deal with each item raised. It lets people sign up to shepherd each action.
Retrospectives make certain talk is straight, negative energies are harnessed, and the way the team works continuously improves.
DevOps means multiple teams need to make changes to production code at the same time. We need to make certain this isn't "too many cooks spoil the broth".
Say Sue, Joe and Eve are collaborating on a birthday lunch. A centralised VCS is like making them work on a one burner stove. They can branch and merge, which is like putting intermediary work in the fridge, then rewarming it. But all the cooks have to line up in a queue because merging can't happen peer-to-peer or in parallel.
Too Many Cooks ...
A Decentralised Version Control System enables developers to integrate edits in parallel, in any sequence, whenever they're ready.
When Eve needs juice to make a Streudel, she doesn't need to wait for the main meal. The integration is distributed - Joe integrates juice and soup, Eve integrates juice and eggs. That way integrating the whole meal is much easier.
In a DVCS each cook collaborates with whoever they need, peer to peer. Here Joe chills the milk and juice to whip up a sorbet. On another burner (local branch) he makes a thickener for Sue's soup.
Joe can use as many local branches as he needs. And, like Sue, Joe makes his work products available to anyone whenever they need it.
One Kitchen Per Cook.
Sue, Joe and Eve swap changes peer-to-peer as often as they like. When a feature matures, they make certain all tests pass, then release it to CI.
The Tech Architect makes certain there's always a stable integrated release ready for showcase.
At enterprise scale, Agile picks up many concepts from Lean, a production process improvement method that minimises expenditure of resources for any goal other than the creation of value for the end customer.
Lean begins by identifying customers by the value they receive. It maps activities that produce value by cycle time ("Takt time"), changeover time, and quality metrics. It tracks pathologies in these measurements to their root causes - waste ("muda"), stress ("muri") and unevenness ("mura").
As these are systematically eliminated, quality improves while production time and cost are reduced. Value Stream Mapping (VSM) can improve business flow at any scale, but to avoid piecemeal it is best to start with the enterprise as a whole and then drill down.
Solving the whole problem. Agile Minds.
Like What You've Seen So Far?
Solving the whole problem.