At UCLA we are building our digital library using Agile methodologies. We use quick iterative sprints, work towards a minimum viable product and continuously deploy as we build. This is a switch from the waterfall building techniques that resulted in many unfinished projects and long waits for simple changes.
I will discuss the Agile tools and methods our teams uses, including
- SPRINT PLANNING
- RETROSPECTIVES
- PAIR / MOB PROGRAMMING
- collaboration tools for remote workers space for pairing
- BDD && TDD - behavior and test driven development I will also discuss the benefits of
- Agile project management and the success we have experienced through using these tools.
broken into minutes...
Hi my name is Jen Diamond I am a developer at UCLA where I am working on a digital repository for the library. I came to UCLA Library from the world of start ups 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 the day after Joshua Gomez was hired to bring Agile practices & the UCLA Library together. He acts a the Supervisor for the development team.
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?
Let's start with Josh's response.
"Money doesn't magically appear in most libraries"
You've heard of good | cheap | fast
You've seen the slider for quality | budget | time The point is
"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."
How are you going to manage that time to create the quality you want?
"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. "
- It's not New
- A Quick History Lesson
- It is not doing things without planning
- We are going to change our minds a lot
- Undisciplined
- Unproven
- Agile helps with
- Ability to manage changing priorities
- Improved project visibility
- Increased productivity
- Improved team moral
- Faster "time to market"
- Better alignment between IT & Business Objectives
- Enhanced software quality
- Simplify development process
- Reduce risk
- Improve software maintainability & extensibilty
- Reduce cost
- Manage distributed teams
- A methodology
- Although you will often see it refered to as such
- A Specific way of developing Software
Agile is really just a set of Prinicpals && Values
to help you deal with uncertainty, change, and stress,
so you can become more Effient Effective Productive;
So you can build a product that people want to use and that you can mantain build apon for years to come.
Values and Guidelines
Business is saying, “I have no idea what’s taking them so long,” and Technology is 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
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.
In Agile, however, the risk curve stays flat. The model of short sprints allows for constant tuning of the design. Continuous integration assures always-functional software that can be productized. An Agile User Acceptance Test, synchronized with development sprints, gives Business the feedback it needs to be responsive.
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. Feedback is gathered and implemented continually and in all, it is a much more dynamic process where everyone is working together towards one goal.
How do we become Agile Make each decision based on the Agile principles & values
The decision making process is how a team becomes Agile.
It is less important what practices the team uses then why they are using it. Look for practices that support your values
The principles & values have enough flexibility to allow teams to develop software in the way that work best them while providing enough direction to help a team continually move toward their full potential
UCLA worked with DCE, Digital Curation Experts, who helped us with our Agile practices and our digital repostory project.
The main things you need to do is:
- Agree to a set of guidelines and practices that you want to follow
- Agree to follow them for one sprint
- Be as dogmatic as you can about your guidelines and practices
- Speak up when the team is not following your own guidelines
- Pick a word or phrase to get you back on track, Our is Tiny Flying Foxes.
- Keep your meetings short
- Have jointly defined acceptance criteria
Train staff. ... 2.Leverage automation. ... Emphasize change of thinking. ... Communicate regularly. ... Foster collaboration. ... Integrate tools. ... Stay Flexible. Concentrate on the End-Product.
Make the meetings count + time limit on the meeting + end on time Set a time for your meeting. Do not go over that time. If you didn't get to everything you needed to in that meeting set up another meeting for that specific thing. Have a guidleine of the topics you want to cover during the meeting. You will get better at pacing the meetings.
- facilitator
- meetings gate keeper
- time keeper
- note take
Jeff Sutherland On the Role of Product Owners
"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.
The Product Owner is the Team member who knows the relative value of what the customer wants.
Works in collaboration with the stakeholders and the team.
Finds out what the stakeholders value. Prioritize and Estimate the value and size of stories
Communication with the stake holders and team.
is responsible for maximizing return on investment (ROI) by identifying product features, translating these into a prioritized list (Product Backlog) deciding which should be at the top of the list for the next Sprint, and continually re-prioritizing and refining the list (Refining the Backlog).
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.
One person Accept or reject work Helps define Done Knowledgeable about the product, empowed to make decisions, engaged. Manage the stake holders expectations. co-located with the team motivate the team celebrate success
This person spends half of their time working with customers and stakeholders and the other half working with the Team implementing the Product Backlog.
If the Product Owner is not involved in the process The customer will not like the result, and more work will need to be done.
What problem are we trying to solve How might we build a solution to solve that problem + is it correct from different perspectives of your users and stake holders What is needed to get the story into “Done”
-
shared understanding of what this means MVP Goals Write all the tickets to the Backlog
-
Write good tickets
- Acceptance for Definition of Done – What is needed to get the story into “Done”.
- the clearer you are in the ticket the more power the person has who is doing it to actually finish without having to contact multiple people to clarify
- goals of definition of Done
- example of the acceptance crtieria (images, sketch, et cetera, anything that makes it clear)
- If it is a new feature or a bug fix write the ticket using the testing style
- Given
- When
- Then
- Expected
- Actual
- example
- Acceptance for Definition of Done – What is needed to get the story into “Done”.
-
Short session for the Solution Developement Team to understand the timebox objectives and accept them as realistic
- Review the objectives, as outlined in the Delivery Plan, to gain a common understanding of what is to be achieved
- Ensure that it is feasible deliver what was initially expected during the Foundation phase, and to re-plan accordingly if this is no longer possible
- Where possible, agree the acceptance criteria for each product to be delivered within the Timebox
-
Access what seems risky for everyone about getting this project to completion on time RISK uncertainty Business Risk - Are we building the right thing? Social - Can these people build this? Technical Risk - Will it run properly and can it scale if needed Cost & Schedule - will we finish the project on time for a reasonable amount of money
-
Train the team.
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.
estimation & prioritization of highest value deliverables
Commitment to delivery is based on pre-agreed resource levels
Highlight any known issues that may affect work time for this Sprint
and plan the velocity accordingly
-
team members also working on other projects
-
vacations
-
holidays
-
meetining
- Velocity measures the rate at which development teams consistently deliver business value
- Tracks how much effort your team has reported as complete for each sprint.
- lets you estimate how much backlog effort your team can handle in future sprints if your team composition and sprint duration stay constant.
- be reasonable with the amount you think you can actually get done
- Scope you will get better at pointing as you complete more sprints
- when planning take into consideration time off and other commitments of the team
- Hannah is taking a 2 day vacation this sprint
- There is a national holiday so the whole team will be out and therefore the sprint is a day shorter
- the team is doing training for a week
-
Planning Poker - Rochambo - Rock Paper Scissors - Tool we use
- team reads the story together
- team estimates (individually so no one is influencing each other)(yes, you can pass)
- team discusses
- team estimates again 0 Task is already completed. 1/2 The task is tiny. 1, 2, 3 These are used for small tasks. 5, 8, 13 These are used for medium sized tasks. 20, 40 These are used for large tasks. 100 These are used for very large tasks. The task is huge. ? No idea how long it takes to complete this task. I am hungry 🙂
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.
Plan Discover Design Develop Deploy Release
Zoom and Slack
In the past I have used Pivotal Tracker,Zenhub and Google Issues. Whatever works for you is what you should use.
Transfer of knowledge
Leverage the knowledge of multiple people. 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 focus while also being fun.
In Person
- large enough font
- be sure the screens are set up so everyone can see them easily without craning their body
- collaborate on a solution
- no one is ever behind and they can loop back in at any time
- learn how to communicate effective and talk about what you are thinkinng out loud
- practice in patience with others and yourself
- transfer of knowledge evevn small things like keyboard shortcuts
- with many sets of eyes it is easier to no make syntax errors
- with many sets of brains it is easier to compine your knowledge to push to a solution and not get stuck
- easy to on board new members to a team
Transfer of knowledge.
You can bring a new team mate or Junior up to speed on a project very quickly by just jumping into a ticket together.
A practice in patience.
It is hard to work with other people, especially at first when you are getting in a groove. It can be maddening to watch someone slowly mouse around looking for the code you are describing. As you get better at communicating with each other it will become more easier. It can also be exhausting communicating.
A few guidelines I like to follow are to use kindness, consideration and respect.
Be kind to yourself, no need to apologize for not typing fast enough or not understanding. Be ready to stand up for yourself if the other person doesn't want to try your idea.
Be considerate to the other person. If they make a spelling error there is no need to immediately correct them unless they move on and they don't notice. If they ask a question just answer it without being condescending.
Respect that the other person may know things you do not and that they are not an idiot. Speak to them as you would wish to be spoken to or even nicer. Be open to listening to other peoples ideas even if you think it may not work.
It takes time to learn to work this way. Take a patience pill and it will payoff.
You don't always have to pair of course but it is a great way to work when learning something new, if you get stuck on something or you are feeling unfocused. You can choose to work this way all the time or set aside time every day to work on stuff together.
THE DONE COLUMN For Us This means the changes have been deployed.
Every day we walk the board together. We have all taken turn leading. This keeps us on track for completing the sprint. What is done What are the blockers Do it fast
Set up clear directions for How-To Deploy and How-to do a Release Have someone each sprint be the release manager. Teach all the devs how to deploy. Automate deploys.
Team reflects on the project and the process Takes actions to be better
Regularly, the team should reflect on how to become more effective, and adjust their accordingly.
- Tool we use Retrium We like this tool because many members of our team are remote (even if remote just means in another building on campus)
- Invest in sticky notes and sharpies
If you are all in the same room
Use different methods
- MoSCOW (great when you have a hard deadline)
this helps you focus on what you really need to get done to call your project done)
- Must - The most vital things you can't live without
- Should - Things you consider as important, but not vital
- Could - Things that are nice to have
- Won't - Things that provide little to no value you can give up on (at least for now) High customer value
- MoSCOW (great when you have a hard deadline)
this helps you focus on what you really need to get done to call your project done)
The team demonstrates completed functionality to stakeholders and gathers feedback
- Formal acceptance of the deliverables by the stake holder and the Technical coordinator.
The Scrum Team and stakeholders (users, other teams, managers, investors, sponsors, customers, etc.) One could say that we invite the whole world to the Sprint Review and this is absolutely true.
So, how do you give a good demo?
Here are a few tips:
Focus on acceptance criteria. You’ve defined what done means for the story (right?), so focus your demo around proving that you’re actually done. Start with the demo in mind. Don’t wait to think about the demo until you’re done with the story. You might be able to write tests that double as demo scripts. And it’s best to plan your demo for a story while it’s fresh in your mind, before you move to the next story. Prepare. Don’t ad lib. Think through an interesting scenario to prove that you’ve satisfied the core acceptance criteria. Create any necessary test data. Use tools like Watir if necessary to get your app into a state where you can start an interesting demo. Practice. Run through the demo at least once. When you’re getting started, you might want to grab a trial version of Camtasia and record yourself giving the practice demo. Painful, huh? That just means you need to work on it. Tell a story. Center your demo around a realistic user solving a real problem. The point is not just to show that the software works, but to show that it’s valuable. Keep it short. If you work on your stories one at a time and get them accepted when they’re ready, you don’t need to exhaustively cover all your acceptance criteria in your demo. Instead, focus your demo on what’s interesting and what’s valuable about each feature. The sprint demo should be the most exciting part of Scrum. It’s when the team gets to show everyone all the value they’re delivering. That’s worth investing a little time to do well. You may find that previously disinterested stakeholders start coming just for the show.
What has worked well for you in sprint demos? What hasn’t worked? Share in the comments.
In Scrum the goal of each iteration is to produce a working increment of the product which can be demonstrated to stakeholders. Naturally then, one of the key meetings in a Scrum sprint is the end of sprint demo (also known as the Sprint Review Meeting).
Here the work that the Scrum team has completed in the sprint is demonstrated and the progress of the team is assessed against the sprint goal.
Purpose of the sprint demo 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 Scrum team any possible amendments to the Product Backlog which would help to maximise value.
Such discussions can inform the planning of the next sprint and the contents of the next sprint backlog. They will often result in stories being added further down the product backlog too.
Format of the sprint demo The sprint demo takes place at the end of the sprint and is attended by the whole Scrum team, including Product Owner and ScrumMaster, as well as relevant stakeholders, management and developers from other teams.
When an organisation has more than one Scrum team working on the same project the teams should consider running their demo together. It’s not just easier to arrange this way – it keeps teams abreast of what the others are working on, which facilitates the sharing of insight and helps to avoid the duplication of work. However at a certain size this may not be practical and representatives from Scrum teams attending each other’s demos may be more practical.
Each Scrum team takes it in turn to update on their progress against their sprint goal and demo the working iteration of the product that resulted from their sprint. Generally I like to do this by user story, with the stories organised in to a logical narrative structure.
Sometimes the team will nominate a member to present the demo and sometimes the task will be shared, with individuals demonstrating the particular parts of the increment they worked on. Again, a personal preference, but I think demos work well where one person leads on the talking and one leads on the demo element.
Preparing for the sprint review meeting The sprint demo shouldn’t take up too much of a Scrum team’s time. Ensuring that the sprint review meeting is an informal affair – where questions, feedback and discussion are welcome – allows for prep time to be kept to a minimum.
Time shouldn’t be spent putting long slide decks together – the focus should be on the work and the demo should only include stories that meet the team’s definition of Done.
Generally a day or two before the end of the sprint I hold a short demo run-through with the team in which we agree the order of the stories in the demo – and make notes on anything we need to set up in order to make the demo flow well. This meeting is kept short (say 15 mins) – but ensures the team have thought the demo through.
Finally it’s important to say that the Sprint review is not a sign off meeting. The Product Owner should have already seen the stories and be happy with them. Discussion and feedback are encouraged – but while this might result in new backlog items, it shouldn’t change whether existing items are considered done.
Product Owner Involvement Individuals and interactions over processes and tools
Passion && Communication
The Product Owner https://www.youtube.com/watch?v=PJwEKldQ-gU apssion && communication
The Product Owner is the Team member who knows the relative value of what the customer wants.
Works in collaboration with the stakeholders and the team.
Finds out what the stakeholders value. Prioritize and Estimate the value and size of stories
Communication with the stake holders and team.
is responsible for maximizing return on investment (ROI) by identifying product features, translating these into a prioritized list (Product Backlog) deciding which should be at the top of the list for the next Sprint, and continually re-prioritizing and refining the list (Refining the Backlog).
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.
One person Accept or reject work Helps define Done Knowledgeable about the product, empowed to make decisions, engaged. Manage the stake holders expectations. co-located with the team motivate the team celebrate success
This person spends half of their time working with customers and stakeholders and the other half working with the Team implementing the Product Backlog.
If the Product Owner is not involved in the process The customer will not like the result, and more work will need to be done.
https://www.scruminc.com/on-fighter-pilots-and-product-owners/
On Fighter Pilots and Product Owners by Jeff Sutherland On the Role of Product Owners
"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. The best way he had learned to deal with an uncertain environment was taught to him as how fighter pilots had to react in combat. John Boyd's OODA loop (Observe-Orient-Decide-Act). Boyd had designed it to help officers survive during combat and defeat the enemy.
AGILE
WHAT AGILE IS NOT
Agile is not a Methodology Agile is not a Specific way of developing Software Agile is not a framework or a process
Agile is really just a set of Prinicpals && Values
to help you deal with uncertainty, change, and stress,
so you can become more Effient Effective Productive;
So you can build a product that people want to use and that you can mantain build apon for years to come.
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
How do we become Agile Make each decision based on the Agile principles & values
The decision making process is how a team becomes Agile.
It is less important what practices the team uses then why they are using it. Look for practices that support your values
The principles & values have enough flexibility to allow teams to develop software in the way that work best them while providing enough direction to help a team continually move toward their full potential
TOOLS & METHODS
TEAMS
SYSTEMS use Kanban Terra Drupal Voyager LABS SERVICES Bucketeer Manifest API Cantaloupe
Stakeholders Group
Use your resources better.
What are your resources?
People
BENEFITS
Timeboxing? Timeboxing is allotting a fixed, maximum unit of time for an activity. That unit of time is called a time box. The goal of timeboxing is to define and limit the amount of time dedicated to an activity. Scrum uses timeboxing for all of the Scrum events and as a tool for concretely defining open-ended or ambiguous tasks.
Kevin S. Clarke 10:37 AM 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.
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.
THE CYCLE
Plan Discover Design Develop Deploy Release
Parinita Mulak
Agile to me is, Having more focus, success through collaboration, more things done , than having more things in progress. More open and responsive to change allows me to be a effective developer. Some of the good features of agile are short iterations, rapid feedback, and automation.
BDD && TDD behavior driven development test driven development
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 for us to learn, share, and grow as a team.
Transparency
Kristian Allen
Previous to utilizing a disciplined approach to Agile (ie diligently tracking tasks, creating tickets, daily scrums, etc...), it was difficult to determine the priority of any number of projects we could be working on. We still have any number of projects we could be working on, but with Agile it is easier to show management/leadership where conflicts can arise from and to present cases to help force priorities for projects.
Andy Kohler
I like the Sprint structure: planning most work ahead of time, with daily standups to help stay on track.
Our team did do a greenfield project recently for TERRA, with multiple people working. It was semi-Agile, maybe: selecting tickets for sprints, writing acceptance criteria. I think one key difference is that the main stakeholders were not closely involved: they weren't in most sprint-related meetings and didn't provide feedback during development, or at least not until we were solidly in beta.
A wonderful serenity has taken possession of my entire soul, like these sweet mornings of spring which I enjoy with my whole heart. I am alone, and feel the charm of existence in this spot, which was created for the bliss of souls like mine. I am so happy, my dear friend, so absorbed in the exquisite sense of mere tranquil existence, that I neglect my talents. I should be incapable of drawing a single stroke at the present moment; and yet I feel that I never was a greater artist than now. When, while the lovely
Mark Matney
I feel like it has helped us size tasks more appropriately; more bite-sized and less big. Progress seems a little more tangible.
Our team size has varied throughout the production of our app. When it was at its maximum size we decided to break away from the other team's standup and just concentrate on our own. Now that our team size is smaller we have rejoined the other teams.
At our stand up we used to say what we worked on yesterday, today, and blockers. We decided to switch to a story centric approach running through each item in the sprint board. We go through the Done column, Release, Review and In Progress column we read each story and see want needs to be done to move it to the done column. YOu don't have to solve every problem in the meeting. The people involved can discuss it after the meeting.
We have four different teams. Each team uses different methods based on what works for them.
We have two different Agile Teams The sprint planning used to be on alternating weeks but now they are both the same day and the stand up for both teams is cancelled on that day.
We make sure our tickets have very clear requirements, Acceptance criteria for completeness, relevant snapshots, links and assets.
Co-location
We are a mixed team of office workers separated into 2 offices and remote workers.
TINY FLYING FOXES
Darrow Cole
Hi Jen, For me, 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.
positive, forward-looking
calling the audience to action; painting a hopeful picture of the future; and/or “paying off” (finishing, resolving) a story or discussion that has run through your talk, so that listeners get a sense of closure.
The end