Don't Just do Agile - AgileDC Conference

Editor's Notes

• #2: Simon Storm – Senior Director of Enterprise Applications – Mary Lynn – Senior Director of Product Management – AgileDC Conference Agile is Dead 5 things outside of the Scrum Today we are going discuss 5 things outside of the scrum team that will dramatically improve your chances for a successful Agile implementation I don’t want to diminish the importance of the team. We have an incredible group who have learned, adapted and thrived
• #3: Financial services organization Over 3000 financial institutions Review PRODUCTS Unique challenges - major banks to tiny community banks AS400 – RESISTANT TO CHANGE Successfully adopted Agile, Continuous Delivery, Infrastructure as Code and working towards DevOps
• #4: DON’T’ WANT TO DISAPPOINT A CHILD on Birthday Lack of Preparation – Failed to assemble gift Better Preparation – Wrap the empty box, have gift ready to go The early warning - of an Agile team – falling apart = Failing to prepare for PLANNING SESSION NIGHT BEFORE Done by one person in a vacuum Can’t plan in a day Team is surprised by work NEED A STRONG PRODUCT OWNER WHO IS INVOLVED = MARY LYNN IS A PERFECT EXAMPLE OF A EXCEPTIONAL PRODUCT OWNER There is nothing worse than disappointing your kid on their birthday LACK OF PREPARATION – LACK OF UNDERSTANDING THE DESIRED OUTCOME Children want to open a present and then immediately play with the present. Unprepared Parent: Open present followed by hours of cursing the manufacture who decided to ship a toy in the lowest common denominator Prepared Parent: Wraps empty boxes. The early warning that I no longer miss is that of an Agile team who is starting to fall apart Preparation for upcoming sprint planning is done the night before…. All the work is done by one person in a vacuum Planning is a surprise to all of the attendees A full day is no where near enough time to complete the planning process
• #5: EXPERTS ON WHAT NOT TO DO EXCELLA RAN THROUGH NUMEROUS CONSULTANTS AND TRAINING SESSIONS BUT MADE US SMARTER WITH EACH FAILURE
• #6: STUCK WITH IT AND SUCCEEDED QUARTERLY TO BI-WEEKLY RELEASES ELIMINATED WEEKEND WORK – INCREASED TEAM MORALE MAXIMIZED THE AMOUNT OF WORK NOT DONE DELIVERED FUNCTIONALITY TO CUSTOMERS MORE QUICKLY TOP 5 THINGS YOU CAN DO OUTSIDE OF THE SPRINT TO MAKE AGILE WORK
• #7: READ QUOTE HITS HOME FOR ME LAST WEEK WE DEPLOYED A MAJOR RELEASE TO THOUSANDS OF USERS REDESIGN OF OUR WEB APPLICATION, INCLUDING TECHNOLOGY, SECURITY, AND UX VERY IMPORTANT FOR MANY REASONS AND ALSO HAS SOME SIGNIFICANT RISK IF THE USERS DON’T LIKE IT OR CAN’T GET THEIR JOB DONE. TALK TO YOU ABOUT HOW WE WENT ABOUT DESIGNING AND DEPLOYING THIS FUNCTIONALITY TO FOCUS ON CUSTOMER EXPERIENCE
• #8: BEFORE WE STARTED SPRINTS, WE HAD TO DETERMINE WHAT WE WERE GOING TO RELEASE? ALL OF IT – TO MUCH FOR OUR FIRST RELEASE, WE WANTED TO STICK TO BASIC RULES FOR AN MVP, SOMETHING BEAUTIFUL, USABLE, AND FUNCTIONAL
• #9: EXPLAIN PICTURE SIT WITH YOUR CUSTOMERS AND WATCH THEM USE YOUR PRODUCTS TEST OUT NEW PRODUCTS IN A SAFE ENVIRONMENT. WE ARE IN FINANCE SO DEAL IN VERY LARGE DOLLAR QUANTITIES… TEST USING PROTOTYPES… SAVES TIME AND MONEY ON BUILDING THE WRONG FEATURES. MAKE SURE YOU GET IT RIGHT. YOU GET TO KNOW YOUR CUSTOMERS BETTER TOOLS CAMTASIA, INVISION, BALSAMIQ, PHOTOSHOP, USERTESTING.COM
• #10: BACK AT HOME, THE SCRUM TEAM WAS ABLE TO LISTEN IN ON THE TESTING OR WATCH VIDEOS. HELPED THEM GAIN EMPATHY FOR THE USER UNDERSTAND THEIR STRUGGLES AND THINGS THEY LIKED ON THE SITE.
• #11: THIS IS A MOCK UP OF OUR FIRST ITERATION OF THE REDESIGNED HOME PAGE. EXPLAIN THE PAGE. We determined that the best slice for us was to update the header/footer, log in, home page, and navigation….and we got to work designing using tools like balsamiq, photoshop, and eventually ended up with a high-dev design we placed in InVision.
• #12: At completion of the first round of testing, here’s what we kept. The logo didn’t even quite maintain the same placement! We ended up keeping navigation, but completely changed the way it worked. The charts were removed completely.
• #13: Ultimately, we ended up here…. Much less content on the page, just give them what they want. Focus on their daily activities We used our customers to ensure that the customer experience was a good one.
• #14: 15 Minutes daily Each person takes a row on the board and moves user stories across it. Prefer the low-tech sticky notes and painters tape so….. They are not considered ready to be moved into a sprint until: UX review Acceptance Criteria Written Text Reviewed Designs done And….
• #15: WHO USES 3 AMIGOS? STORIES CAN’T BE ACCEPTED WITHOUT 3 AMIGO The three amigo consists of a developer, business analyst, and QA reviewing a story. The BA, representing the product owner, presents the story, and the three of them work together to refine it and identify any missing requirements or edge cases. PRE AMIGO, RE-AMIGO…
• #16: LEAN CONCEPT –MEASURE AND LEARN Measure the success of each feature you deploy so that you can learn and adjust the feature, if necessary. Despite your best prototype testing, you may learn that the majority of users are not using something in the way it was intended. While not great, at least you know and can adjust. EXPLAIN HEAT MAP GOOGLE ANALYTICS, CLICKTAIL
• #17: WE BUILT HIGHLY CONFIGURABLE APPLICATION – When we knew the least Configurable parts never changed 3 developers to make a change Simple changes were difficult ANYONE can implement a full feature. RINSE – Removed SOAP (Web Services Tier) SIMPLY THE ENVIRONMENT – Co-location, get rid of multiple hats, AGILE DIDN’T WORK FOR US – AGILE was not set up to succeed SPRINT 0 One of my favorite catch phrases is “At the beginning of the project is when you know the least” One of the most prevalent comments I hear is “Agile didn’t work for us”. Mary Lynn ran through several team and process points that are critical to success. But there is a technical component as well that needs to be considered. The main issue with infrequent releases is the need to get the feature in now which results in gold plating. A second symptom that becomes apparent is the need to create a very dynamic and highly configurable system While this sounds like a good idea, it is detrimental when done “when you know the least”. We fell into the trap of creating dynamic listings so we could add fields as needed. The issue we ran into was adding dynamic fields was very difficult, creating logical layouts was difficult and making changes to text on the pure website was difficult We had a situation where we needed the database guy to do update a stored procedure, a the services guy to update the web service, and then the developer could implement the functionality, but before it was complete it would go to the UI guy to clean up the screen. You cannot be agile if this is the only way to add a feature.
• #18: EVERYONE WANTS 2 WEEKS 2 WEEKS  8 WEEKS  2 HOURS We deploy code every other week – Amazon Deploys 11.6 seconds Small changes are easier to digest Small changes reduce the risk of introducing issues We made migrating a development task and a non-event It was well planned to do this slide last. I can speak for hours on this topic. The main challenge that we faced was the two week syndrome BAs wanted 2 weeks to define requirements Developers wanted 2 weeks to code QA wanted 2 weeks to test Operations wanted 2 weeks to ensure production readiness I wanted the team to perform 2 week sprints Mary Lynn already explained the importance of backlog grooming which really means that all the BA work should be done prior to the start of the sprint. She also mentioned the importance of small stories. This cuts the 8 weeks back to about 4. Still too long. The solution is Continuous Delivery. First, by automating deployments, building confidence and making the deployment process a routine non-event Confidence comes from consistent deployments, but Infrastructure as Code is really the key to creating consistency Slow Delivery IT cannot keep up with business demands Resistance to changing requirements Manual Testing QA tests the same functionality over and over Developers move on to new tasks and then have to switch gears to fix bugs Manual Deployments Long detailed ECS documents Inconsistent environments Scheduled releases for off hours
• #19: 10 deploys per day Dev & Ops Cooperation at Flickr John Allspaw & Paul Hammond
• #20: Velocity Culture Jon Jenkins Amazon Deployments from May 2011 11.6 seconds – Mean Time Between Deployments 1079 – Max number of deployments in an hour 1000 – Mean number of hosts receiving a deployment 30,000 – Max number of hosts receiving a deployment
• #21: EVERYONE WANTS 2 WEEKS 2 WEEKS  8 WEEKS  2 HOURS We had a major release where we put in months of work. EVERYONE wants to get back to two week releases We had issues migrating through environments We had one problem that we couldn’t nail down the cause easily because so much changed in one release BUT we made a silly mistake and fixed in HOURS….ROLLED FORWARD It was well planned to do this slide last. I can speak for hours on this topic. The main challenge that we faced was the two week syndrome BAs wanted 2 weeks to define requirements Developers wanted 2 weeks to code QA wanted 2 weeks to test Operations wanted 2 weeks to ensure production readiness I wanted the team to perform 2 week sprints
• #22: Mary Lynn already explained the importance of backlog grooming which really means that all the BA work should be done prior to the start of the sprint. She also mentioned the importance of small stories. This cuts the 8 weeks back to about 4. Still too long. The solution is Continuous Delivery. First, by automating deployments, building confidence and making the deployment process a routine non-event Confidence comes from consistent deployments, but Infrastructure as Code is really the key to creating consistency Slow Delivery IT cannot keep up with business demands Resistance to changing requirements Manual Testing QA tests the same functionality over and over Developers move on to new tasks and then have to switch gears to fix bugs Manual Deployments Long detailed ECS documents Inconsistent environments Scheduled releases for off hours
• #23: In the end, it’s up to you to give your kid the birthday they deserve and to give your customers high value products they love. Agile can help you get there. Don’t give up if you screw up. Just try again and you’ll get there. It’s definitely worth it. Thank you for giving us the opportunity to share some of our failures and successes with you today. Simon and I love talking about this so please feel free to grab us later if you have any questions.