Hi my name is Jen Diamond I am a developer at UCLA where my Team and I are working on a digital repository for the library.
I came to UCLA Library from the world of startups where Agile was a daily practice.
I was very fortunate to be mentored by Pivotal Labs who are top of the game consultants. Pivotal Labs is where many large enterprises and I learned Best Practices and the Extreme Programming flavor of Agile.
I came to the UCLA Library at the same time Joshua Gomez was hired to bring Agile practices & the UCLA Library together.
I'm going to talk about specifics aspects of Agile; what they are and how my team uses them.
Often when a project gets built
the Business people are saying, “I have no idea what’s taking them so long,”
and the Tech people are saying, “They never knew what they wanted in the first place.”
To mitigate the culture clash between Business and Technology,
Agile creates many points of contact between the two groups
Agile is a term used to describe approaches to software development emphasizing
- incremental delivery,
- team collaboration,
- continual planning,
- and continual learning, instead of trying to deliver it all at once near the end.
Agile focuses on keeping the process lean and creating minimum viable products (MVPs) that go through several iterations before anything is final.
- Agile is not New
- Agile is not doing things without planning
- Agile is not We are going to change our minds a lot
- Agile is not Undisciplined or Unproven
- Agile is not a Specific way of developing Software
- Agile is not a methodology
- although you will often see it referred to as such
Agile is really just a set of Prinicples && Values
to help you deal with uncertainty, change, and stress.
Being Agile helps you more effient, effective, and productive,
so you can build a product that people want to use
and that you can maintain and build upon for years to come.
So how do you become Agile?
You make each decision based on Agile principles & values
Agile refers to a set of values and principles put forth in the Agile Manifesto which places primary value on
- Individuals and interactions rather than processes and tools;
- Working software rather than comprehensive documentation;
- Customer collaboration rather than contract negotiation; and,
- Responding to change rather than following a plan.
It is less important what practices the team uses then why they are using it. Look for practices that support your values
Things you need to do to start being Agile are:
- Communicate regularly - co-locate as much as possible and find a good tools for working remotely
- Integrate tools - figure out which ones work for you
- Train your staff - integrate continued learning
- Leverage automation - set up automated testing & deployment
- Foster collaboration - through pair and mob programming & efficient meetings
- Stay Flexible - be willing to change things that are not working or that are not needed
- Concentrate on the End-Product
Another very important aspect of Agile is having the Product Owner & Stakeholders engaged in the process.
"The Product Owner works in a more uncertain world,
constantly having to stay in touch with and react to
the customer, the team, and the competitive landscape. ~Jeff Sutherland
The Product Owner is the only person who has full and final authority over the project.
The Product Owner is responsible for the product vision, the business plan, and the outcome.
They
- are knowledgeable about the product
- help define Done
- manage the stakeholders expectations
- motivate the team
- celebrate success
and more work will need to be done.
When you first start a project or decide to bring Agile into an existing project you will start by having some meetings.
Make your meetings count
- Put a time limit on each meeting
- End on every meeting on time
If you didn't get to everything you needed to in that meeting set up another meeting for that specific thing
with only the people who need to be involved.
You will get better at pacing the meetings.
A longer meeting where you figure out
- What problem are we trying to solve
- How are we going to build a solution to solve that problem
- is it correct from different perspectives of your users and stakeholders
- What is the MVP - Minimal Viable Product that we can build that will satisfy the criteria and nothing more
- Onnce you figure out what is needed to get it done
- Break down all the tasks into small pieces and write tickets for each actionable item
- Write all the tickets into the backlog
Writing good tickets is really important.
Good tickets have all the info for what is needed to get the story completely finished.
- There is Acceptance criteria for the Definition of Done
- All content is included and ready to be used
- You can also add images, a sketch, a url; anything that makes the ticket clear
If you are clear in the ticket
than the person doing it won't have to contact multiple people to clarify it saving time and frustration.
+ If it is a new feature or a bug fix write the ticket using the testing style
+ Given - I'm on this page
+ When - I do this
+ Then - This happens
+ I Expected this to happen
+ This Actually happened
+ have an example so the bug can recreated
+ show examples like screenshots and urls
- Short session for the Team to go over the plan of action
and get a shared understanding of the objectives and accept them as realistic-
Review the objectives, as outlined in the Delivery Plan
-
Ensure that it is feasible deliver what is expected
-
And to change the plan accordingly if this is no longer possible
-
Access what seems risky for everyone about getting this project to completion on time
-
shared understanding of what this means
-
Make sure your devs have the training and guidance necessary to work with the language and tools you are using for the project.We hired Notch 8 to give the entire Team a week of Rails training. We also hired DCE - Digital Curation Experts to work with us on the first phase of our project. We leveraged their expertise to help us get our project up fast. They paired with our devs and also coached us in Agile practices.
After the initial Phase of getting the project rolling our devs got a dedicated hour a day for learning. Many of us found that we had a hard time using that time so this Quarter we decide to dedicate every Friday to learning.
In this event, the team collaborates to discuss the objectives for the next iteration or sprint. It also summarizes the work done and determines the team backlog required for the next iteration.
This is the ‘do’ step where the development of the software, its design and coding and testing takes place. The team collects user stories and prepares for the next step, that is Iteration Review.
The team shows the tested deliverable to the Product Owner, who then reviews the completed work and ascertains whether all criteria have been met.
In this event, the team evaluates the entire process of the iteration from the first step. It essentially works on any improvements that are gathered in previous iterations. New problems are identified along with their causes. Before the team starts the next cycle again, team backlog is refined for future reference.
The iterations are repeated for optimizations and improvisations and, the lessons learned from previous cycles are applied in the next cycle. Until a fully functional software is ready to hit the market.
You can do this with just the project manager, product owner and lead dev or with all the members of your team.
The goal is to get the backlog in shape so your sprint planning meeting can be focused.
This means identifying what the goals of your Sprint are and identifying which tickets you need to complete these goals
Sprint planning is a meeting when the Team determines which tickets they will work on during the next sprint.
The Teanm estimates& prioritizes the highest value deliverables.
During this meeting be sure to acknowledge and highlight any known issues that may affect work time for this Sprint and plan the velocity accordingly. such as:
- team members also working on other projects
- vacations
- holidays
- meeting times
- training
Estimate the approximate time it will take to complete each ticket.
Everyone has a vote. Many teams use Rochambo to point their tickets.
We use https://play.planningpoker.com which is great for remote teams.
- The team reads the story together
- team estimates (individually so no one is influencing each other)(yes, you can pass)
- team discusses why different people chose different numbers
- the team makes a decision on how to point it
- 1 - Simple task. About an hour or less of work
- 2 - Normal task. About half a day or less of work.
- 3 - Normal task. Approximately a whole day of work.
- 5 - Heavy task. 2-3 days of work.
- 8 - Very heavy task. About a week of work.
- 13 - Too large
- PASS
- Time Boxing
- a fixed period of time, at the end of which an objective has been met.
You will get better at pointing the more sprints you do.
Collaboration on tickets leverages the knowledge and skill of multiple people. Devs spend less time getting stuck on problems.
When the whole team works on
the same thing
at the same time
in the same space
on the same computer.
All the skills and knowledge are combined together.
Our team does a lot of pair programming. We have a dedicated time block set aside each day where we all join a zoom room and work on tickets together. Sometimes we may not use it for a few days and just work on our own but we all know that if we have any questions we can just Slack our team mates and walk them through our blocking point so no one stays stuck for days. It is amazing what another set of eyes, ears, brain and a different perspective can add. It is also easier to stay focused while also being fun.
Yes really stand up. You stand up because it helps to keep the meeting short.
THE DONE COLUMN For Us This means the changes have been deployed.
Everyday we go through every ticket on the board together and assess what is Done what is in Progress and if there are any blockers.
Do it fast. We aim for 5 minutes.
Generally in Agile, Testing is not a separate phase, but an integral part of software development, along with coding. Testing and coding are done at the same time
Testing not only facilitates the early detection of defects
but they also reduce the cost of bugs by fixing them early.
- Rapid. They are fast because the computer executes them.
- Comprehensive. You can easily run automated tests for your entire program when you make a change, instead of just the part of the program on which you are currently working.
- Repeatable. Once you have written a suite of automated tests, they will all be executed every time you want to run your tests. You don't have to worry about forgetting any of the tests.
Generally speaking, there are two kinds of automated tests:
- Unit tests are used to test how a single unit of your program works.
- Integration tests are used to test how the entire program works with other systems.
A lot of Agile shops to TDD -Test Driven development or BDD Behavior Driven Development were you write your tests first which help you figure out your requirements and then write the code to make the tests pass.
We don’t do TDD but we do write tests for each piece of work we do. We use a combination of unit tests and integration tests. We have 96% test coverage and confidence that when we add a new feature we’ll know if we are breaking something else.
Deploy Early Deploy Often
We don't have automated deployment currently. That is one of our Goals but we do have a process.
Before our code can checked to see if it can be merged to master in our Github
our commit must be reviewed by another dev on the team.
This helps prevent human error not caught by other checks in our Github.
Once the commit is approved our Github setup runs Travis
which runs Rubocop, a linter that enforces us to use Ruby & Rails best practices.
Travis then runs pa11.y which checks our code for accessibility offenses
and then Travis runs our tests again in Github before the code can be merged.
If all tests and checks pass then the branch can be confidently merged to master.
We have similar checks installed for our deployment process as well.
- We have set up clear directions for How-To Deploy and How-to do a Tagged Release
- Someone is chosen each sprint be the release manager
- All the devs have been taught how to deploy
- We currently deploy several times a week as needed
An Agile retrospective is a meeting that's held at the end of a sprint or phase.
During the retrospective, the team reflects on what happened in the iteration
and identifies actions for improvement going forward.
A good retrospective should:
- Inspect how the last Sprint went with regards to people, relationships, process, and tools;
- Identify the things that went well, and potential improvements
- Create a plan for implementing improvements Retros are a great way to discuss problems as they arise instead of waiting until they get so large they blow up. It is a safe space to voice concerns and problems. There should be no blame placed only solutions offered.
The primary purpose of this ritual is to enable continuous improvement.
This means that teams will get better over time.
There are many different ways to do a retro.
It doesn't matter which one choose just be sure not to skip them even if they are short they are helpful.
The goal of each iteration is to produce a working piece of the product which can be demonstrated to stakeholders.
For the Demo
- the team demonstrates completed functionality to stakeholders and gathers feedback.
- there is formal acceptance of the deliverables by the stakeholder and the Technical coordinator
Purpose of the sprint demo is invaluable for keeping stakeholders up to speed with the progress of product development.
It allows them to feedback and discuss with the Product Owner and the Team
any possible amendments to the Goals which would help to maximise value.
I asked for quotes from all of my co-workers for this talk. I asked them, How has using Agile methodologies personally changed the way you work on projects for the Library?
Joshua Gomez I believe Agile is necessary because the number of projects the library proposes
and the scope of those projects are not realistically achievable given the available resources.
Conceptual tools like the trade-off slider teach us that, if scope is not adjusted,
then time, budget, or quality must adjust in its place.
Money doesn't magically appear in most libraries, so that leaves time and quality.
Either you miss deadlines or your produce software that nobody likes, including the developers.
Nobody wants those outcomes, so scope should be reduced instead.
Agile planning is built on the idea of realistically estimating the amount of work that can be done
and adjusting scope to fit in each sprint.
My goal is to push this mentality up the chain and to be more realistic and strategic in bigger picture planning.
Mid and high level managers need to ask themselves how many of their desired projects
can realistically be completed over the next year, the next 3 years, and the next 5 years.
Then start breaking projects up into phases that can be achieved each quarter,
so that you can evaluate and adjust to problems before it's too late.
What Agile tools and guidelines are important to use?
Whichever ones that make your process better
and makes the pace of your work sustainable.
Your happiness counts!
Stephen Gurnick
Using agile workflows day-to-day, it is no longer a mystery what my colleagues are working on. We created a safe space
Darrow Cole
Agile has moved projects from being vertically integrated, long term personal endeavors to building with small pieces in a team environment. Having a team on a project is great.
Kevin S. Clarke I'd say our switch to agile methodologies has encouraged incremental progress and more mindfulness about the reasonableness of scope. Personally, that's meant less anxiety about hitting important deadlines.
Less anxiety also, for me, often translates into improved productivity.
Parinita Mulak
Agile to me is, Having more focus, success through collaboration, more things done , than having more things in progress. Being open and responsive to change allows me to be a more effective developer. Some of the good features of agile are short iterations, rapid feedback, and automation.
Andy Kohler I like the Sprint structure: planning most work ahead of time, with daily standups to help stay on track.
Hardy Pottinger The notion of Continuous Integration as an attitude that can drive how we write stories (the smaller the better) as opposed to a process that runs and checks our work for us... has had a big impact on how I approach every task in my life, not just the coding I do for work.